Support directed identity for non-interactive grants

[raducristianpopa]

Context

When requesting a grant, the client field represents the wallet address of the entity that makes the request. To address the privacy concerns for the in browser implementation of Web Monetization we want to support a directed identity approach for non-interactive grants.

More context: Open Payments User Wallet Directed Identity Document

Todos

• The client field should be an object that accepts the following properties: jwk or walletAddress (mutually exclusive - only one of them)
  • jwk should be constrained to the format:

    open-payments-specifications/openapi/wallet-address-server.yaml

    Lines 166 to 197 in a0d4177

    	json-web-key:
    	type: object
    	properties:
    	kid:
    	type: string
    	alg:
    	type: string
    	description: 'The cryptographic algorithm family used with the key. The only allowed value is `EdDSA`. '
    	enum:
    	- EdDSA
    	use:
    	type: string
    	enum:
    	- sig
    	kty:
    	type: string
    	enum:
    	- OKP
    	crv:
    	type: string
    	enum:
    	- Ed25519
    	x:
    	type: string
    	pattern: '^[a-zA-Z0-9-_]+$'
    	description: The base64 url-encoded public key.
    	required:
    	- kid
    	- alg
    	- kty
    	- crv
    	- x

• Backwards compatibility for the client field - should be available to use in both formats (string and the new object) for some time to allow people to migrate.

[mkurapov]

@raducristianpopa with this, should we also add display to the client field in that case?

https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#name-providing-displayable-clien

[raducristianpopa]

Not sure if the display field actually fits the privacy concerns for this use-case. 🤔

@sidvishnoi Were there any discussions about directed identity and the privacy concerns regarding the incoming payment grant?

[sidvishnoi]

Not directly involving me. @asurkov can share more perhaps.

[asurkov]

My impression was that we all agreed it should be implemented, but no actual work has been started yet. The feature requires server-side support before we can make corresponding adjustments on the client side.

That said, we should resurrect this effort, since it’s considered blocking for the threat model. The model itself is built on the assumption that directed identity will be in place.

[mkurapov]

@raducristianpopa

Not sure if the display field actually fits the privacy concerns for this use-case. 🤔

As in, the worry here is that if display is provided, that information might get back to the recipient and see who has been sending them payments? For example, if there is a feature on the receiving ASE to get a list of all of the non-interactive grants for the receiving wallet address?

[raducristianpopa]

@raducristianpopa

Not sure if the display field actually fits the privacy concerns for this use-case. 🤔

As in, the worry here is that if display is provided, that information might get back to the recipient and see who has been sending them payments? For example, if there is a feature on the receiving ASE to get a list of all of the non-interactive grants for the receiving wallet address?

Just went through the GNAP Spec again. I totally missed that display is optional. If clients have the option to provide it or not, I would say that we can add it.

[asurkov]

Honestly, I’m not quite sure I follow how the display is connected to the issue. The original issue was that if a monetization link is included on a website, where the other side isn’t a website wallet receiving funds from users but an OpenPayments-backed tracker, it could be used for cross-origin tracking. The tracker can use the client field, which contains the user’s wallet address and which uniquely identifies them (at least until the user changes their wallet), as part of the incoming payment grant request that the browser sends whenever it encounters a monetization link on a website. What do I miss?

[mkurapov]

This particular issue has to do only with the updates to the Open Payments OpenAPI specification itself, not the implementation. You are right @asurkov in that the original privacy concern doesn't have to do with the display value but since we are changing the client definition, we should also consider supporting display if we want to stick to the GNAP specs