Presentation with key binding

[OR13]

A stripped down version of presentation exchange, where:

• The holder gets a "challenge token" from the verifier (stateless nonce)
• The holder prepares a disclosure of an sd-jwt with key binding for the verifier
• The holder submits the sd-jwt and key binding token

The verifier first confirms, the challenge token is signed by them (no data base lookup).

The verifier verifies the sd-jwt presentation, and in doing so, confirms the key binding token matches the confirmation claim in the credential, and that the key binding token nonce, matches the challenge token.

The only information exchanges between holder and verifier is the "nonce" / "challenge token".

The exchange could be done over an encrypted channel other than TLS, for example HPKE with aad context binding.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dune	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 7, 2023 8:19pm

[OR13]

I added a second script which assumes that a verifier would accept any key binding token, assuming it used a nonce that is not older than 5 minutes.

this eliminates the interaction with the verifier, but it does not allow the verifier to force the holder to commit to specific context, in the same way that a challenge token as a nonce does.

[peppelinux]

a challenge is supposed to change during time, while a .well-known probably would be provided as a static content (in my relative assumption).

I'm wondering if a wellknown endpoint is something good for a dynamic value

[OR13]

I agree... I tried to keep the interfaces similar to https://www.rfc-editor.org/rfc/rfc8555.html

But its not doing the same thing (its inverted, the prover posts to the challenge endpoint, instead of provisioning the challenge endpoint).

The idea was that serving a challenge token is very similar to serving a "status list credential".

Both contain signed claims that can have nbf and exp.

As a verifier, my policy might be to update my challenge once a day, or once a minute.

This is similar to the scenario in OIDC, where i might rotate parts of my open id configuration:

{
  "issuer":"http://acmepaymentscorp",
  "authorization_endpoint":"http://acmepaymentscorp/oauth/auz/authorize",
  "token_endpoint":"http://acmepaymentscorp/oauth/oauth20/token",
  "userinfo_endpoint":"http://acmepaymentscorp/oauth/userinfo",
  "jwks_uri":"http://acmepaymentscorp/oauth/jwks",
  "scopes_supported":[
    "READ",
    "WRITE",
    "DELETE",
    "openid",
    "scope",
    "profile",
    "email",
    "address",
    "phone"
  ],
  "response_types_supported":[
    "code",
    "code id_token",
    "code token",
    "code id_token token",
    "token",
    "id_token",
    "id_token token"
  ],
  "grant_types_supported":[
    "authorization_code",
    "implicit",
    "password",
    "client_credentials",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "subject_types_supported":[
    "public"
  ],
  "id_token_signing_alg_values_supported":[
    "HS256",
    "HS384",
    "HS512",
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "ES512",
    "PS256",
    "PS384",
    "PS512"
  ],
  "id_token_encryption_alg_values_supported":[
    "RSA1_5",
    "RSA-OAEP",
    "RSA-OAEP-256",
    "A128KW",
    "A192KW",
    "A256KW",
    "A128GCMKW",
    "A192GCMKW",
    "A256GCMKW",
    "dir"
  ],
  "id_token_encryption_enc_values_supported":[
    "A128CBC-HS256",
    "A192CBC-HS384",
    "A256CBC-HS512",
    "A128GCM",
    "A192GCM",
    "A256GCM"
  ],
  "token_endpoint_auth_methods_supported":[
    "client_secret_post",
    "client_secret_basic",
    "client_secret_jwt",
    "private_key_jwt"
  ],
  "token_endpoint_auth_signing_alg_values_supported":[
    "HS256",
    "RS256"
  ],
  "claims_parameter_supported":false,
  "request_parameter_supported":false,
  "request_uri_parameter_supported":false
}

I know these are not necessarily dynamic, or frequently changing, but it would be a security issue if they were immutable, since the issuer would not be able to advertise that they removed support for a now broken, but previously supported configuration.

I'm sure changes to configuration resources would break things, but I imagine it is allowed.

I do think it might be a better pattern to discover the "challenge" and "presentation" endpoints from the issuer metadata, assuming they are part of interacting with the issuer.

In a scenario where presentations are encrypted to the issuer, the issuer's keys also need to be discovered... the the challenge token could contain everything needs to reply, or the presenter could dereference several URLs and assemble what is needed to submit a presentation.

[OR13]

There was some discussion in the last WICG call about a "minimal version of OIDC4VP" that just delivered nonces,
my goal was to define an http interface that had the minimally required properties, not one that was necessarily compatible with OIDC... although it both can be accomplished at the same time, that would be the best case.

[peppelinux]

Wondering about a nonce/challenge endpoint I wrote the following draft, trying to put all the things discussed with other authors and looking for something reusable in context even different from a specific protocol

https://peppelinux.github.io/draft-demarco-nonce-endpoint/draft-demarco-nonce-endpoint.html

[OR13]

What you wrote is essentially what I want, in your example the token is encrypted to the verifier / nonce issuer, in mine it is just signed as an SD-JWT (for no reason, since no SD features are used).

Our use case for the nonce is just to support the proof of possession / key binding token.

We'd prefer to not need all of OIDC4VP to submit presentations with key binding, and we are interested in delivering the nonce over channels other than HTTPS, perhaps even RF / QR channels.

I think some informative round trip examples of the nonce use might be helpful, especially over http.

You would not need to add text, just a section with introductory context and then a reference to:

• https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-11.5
• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-01#section-7.1

(and gather a few other specs, that require opaque nonces).

[OR13]

Blocked pending merging of w3c/vc-data-model#1379

[OR13]

Based on how things have progressed at IETF and W3C I am going to merge this, and then I will open a new PR to simplify.

We only need one "external endpoint, to take submissions", and we can probably make it front channel capable, so it can redirect the user on success or error cases.