Hi Justin,
I can not answer for the motivations to do deferred POP, but OpenPubkey [0]
provides a way to do a key binding and defer the POP to a later point using
JWS signing rules which does not seem to have the identified problem.
It would work as follows:
1. Bind keypair (upk,usk) to JWT by creating JWT token with cnf claim set
to pk
2. Later to add to POP to JWT, sign JWT with usk and include this new
signature as a additional signature on the token. Token is now only a JWS
but not a JWT because JWTs can not have more than one signature.
3. Anyone to whom the token is presented rejects token if token does
include a second signature s.t.
JWS_VERIFY(token.payload.cnf, token, token.sig2) = 1
> (They register the credential after seeing the PoP exchange, but before
finishing). This is a very subtle change in the semantics that likely
invalidates a lot of security assumptions.
The approach used by OpenPubkey overcomes this problem by having the POP
depend on the JWT payload itself. This forces an order on the token
issuance and POP.
The JWS token would look like:
```
{"payload":{
"iss": "https://issuer.example.com";,
"nonce": "iPk...",
"cnf": <upk>,
"signatures":[
{
"protected":{
"alg": "RS256",
"kid": "1234",
"typ": "JWT"
},
"signature": "GqjU... (Issuer's signature)"
},
{
"protected": {
"alg": "ES256",
"typ": "POP",
"upk": {
"alg": "ES256",
"crv": "P-256",
"kty": "EC",
"x": "cv...",
"y": "Wh..."
}},
"signature":"TBa... (Client's signature)"
},
]}
```
OpenPubkey diffs slightly because we don't have a cnf claim and so must do
the binding in the nonce claim, but this idea seems adaptable to the
deferred POP need. We document our JWS token formats here[1]
[0]: OpenPubkey: Augmenting OpenID Connect with User held Signing Keys -
https://eprint.iacr.org/2023/296
[1]: A guide to PK Tokens -
https://github.com/openpubkey/openpubkey/blob/main/docs/pktoken.md
On Thu, Jun 5, 2025, 13:16 Watson Ladd <[email protected]> wrote:
> On Thu, Jun 5, 2025 at 9:45 AM Justin Richer <[email protected]> wrote:
> >
> > Hi Chairs and WG,
> >
> > Back in Bangkok, we presented the draft
> https://datatracker.ietf.org/doc/draft-richer-oauth-tmb-claim/ that
> introduces, in a concrete way, the notion of getting a token bound to a key
> that you don’t possess. As we discussed, this is a topic that keeps coming
> up in the OAuth space and is usually dutifully pushed aside for the sake of
> simplicity (and some would argue sanity).
> >
> > The chairs mentioned pulling together an interim meeting for the OAuth
> WG for us to discuss this topic ahead of Madrid, to see if there was
> anything more we as a community want to do with it. As we’re now more than
> halfway between the meetings, we wanted to bring that up again and see if
> that interim can get scheduled soon. I’d also like to encourage people to
> read through the draft and open the discussion here on the list more.
>
> This draft, plus the properties of many existing signature schemes
> like RSA and ECDSA, creates the possibility of an attacker getting a
> credential issued that will work with an already existing PoP exchange
> without actually having possession of the key. (They register the
> credential after seeing the PoP exchange, but before finishing). This
> is a very subtle change in the semantics that likely invalidates a lot
> of security assumptions.
>
> Why do we need to do this?
>
> >
> > — Justin
> > _______________________________________________
> > OAuth mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> OAuth mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
