[Openid-specs-ab] A/B Connect WG eeting notes August 21, 2025

[Frederik Krogsdal Jacobsen]

Date: 21/08/2025

Attendees: Michael Jones, Frederik Krogsdal Jacobsen, Ethan Heilman, Chris
Phillips, Dick Hardt, Andrii Deinega, George Fletcher, Filip Skokan, Bjorn
Hjelm, Brian Campbell

   - Proposed “sign” extension to WebAuthn (slightly off-topic discussion):
      - Link: https://github.com/w3c/webauthn/pull/2078
      - Allows signing arbitrary data using a key which is not stored on a
      hardware authenticator, but which is cryptographically
associated with the
      authenticator.
      - Related draft spec for the cryptography (ARKG):
      https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/
   - Events: there will still be an OIDF meeting on Monday afternoon before
   IIW. No updates on DICE.
      - Discussion of OpenID Connect Key Binding:
      - Changed to no longer “abuse” the nonce, and now explicitly requires
      validating the Authorization Code instead by putting it into the
DPoP proof
         - Filip’s advice: hash the code before putting it into the proof
         to ensure it’s not too long
         - Maybe call it code_hash (don’t call it c_hash since that is
         already in use)
      - How can an app prove which user is using it? Proof-of-possession on
      the ID token. Example use case: proposal to use HTTP message signing to
      identify client between requests in MCP. Would allow MCP server to bind
      client to requests, and also make decisions based on the
contents of the ID
      token
         - Ethan: some use cases sign a HTTP request, then take the public
         key and send it to an auth server.
            - Question: why are those not just bearer tokens? Answer: They
            is holder bound via the public key in the ID token
         - Is this mixing authorization into the ID token? Should this
      actually be in an access token instead, or should it be a new type of
      token?
         - Mixed opinions on this, especially for MCP-like use cases
         - Mixed opinions: One difference may be that ID tokens are often
         one-time use, while access token are often reusable
      - Related draft spec: OpenID Connect UserInfo Verifiable Credentials
         - Link:
         https://openid.net/specs/openid-connect-userinfo-vc-1_0.html
         - Chair request to proposers: how does the new proposed Key
         Binding spec compare to this?
         - We will try to find archives of the discussion of the
         UserInfo-VC spec at the time it was proposed
      - What do we want to do?
         - The pattern is already in use, so it might be worth standardizing
         - Informal poll revealed no consensus on whether this should be
         standardized or is an “improper” use of ID tokens. Some WG
members did not
         have enough context on use cases to form a decision.
         - Decision: we will discuss this for one more week before a formal
         call for adoption.
      - Is there any existing consensus/prior art regarding the distinction
      between ID tokens and “other” (e.g. access) tokens?
         - Not really.
         - Don’t use the ID tokens for repeated API calls, but otherwise
         not clear
      - Ethan: the proposed spec is not only useful for sending the ID
      token to other audiences, but also for adding some security
         - Other members of the WG did not quite understand how - a more
         detailed explanation would be useful
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250821/2f7fbe77/attachment.htm>