You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
raducristianpopa
changed the title
[PLACEHOLDER] Support directed identity for non-interactive grants
Support directed identity for non-interactive grants
Nov 6, 2024
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
client
field should be an object that accepts the following properties:jwk
orwalletAddress
(mutually exclusive - only one of them)jwk
should be constrained to the format:open-payments/openapi/wallet-address-server.yaml
Lines 153 to 178 in f259f30
client
field - should be available to use in both formats (string and the new object) for some time to allow people to migrate.The text was updated successfully, but these errors were encountered: