BK Comments 10.2

[Nat Sakimura]

Section 10.2

   (b)  Verifying that the symmetric key for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

Similarly to the previous point, you also need to check the signature,
which will always be there.

   (d)  Authorization Server is providing an endpoint that provides a
        Request Object URI in exchange for a Request Object.  In this

I don't think this is a complete sentence (and it's definitely not a
parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
summary of this method would be "Delegating the authorization check to a
separate "Request Object to Request Object URI" endpoint on the
Authorization Server".  (The writing in the rest of this paragraph could
also use an editing pass.)

   (e)  A third party, such as a Trust Framework Provider, provides an
        endpoint that provides a Request Object URI in exchange for a
        Request Object.  The same requirements as (b) above apply.  In
        addition, the Authorization Server MUST know out-of-band that
        the Client utilizes the Trust Framework Operator.

The Authorization Server also has to trust the third-party provider to
actually do its job and not misbehave, right?

[Nat Sakimura]

This one has three issues in it.

‌

Point 1: (b) needs to state that signature needs to be checked.

Current (b) states:

   (b)  Verifying that the symmetric key for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

This actually should be fine technically, but since in our case, it is always signed and encrypted in the case of the encrypted request object, checking the signature suffice. So, we can actually remove (b).

Point 2: (d) Incomplete sentence

The fix Ben proposes is not correct. I suppose we can fix the issue by changing it as follows. (Bold means insertion, strike through means deletion.)

(d) When Authorization Server is providing an endpoint that provides a
Request Object URI in exchange for a Request Object. In this
case, the Authorization Server MUST perform Client
Authentication to accept the Request Object and bind the Client
Identifier to the Request Object URI it is providing. Since
Request Object URI can be replayed, the lifetime of the Request
Object URI MUST be short and preferably one-time use. The
entropy of the Request Object URI MUST be sufficiently large.
The adequate shortness of the validity and the entropy of the
Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for
the validity time would be less than a minute and the Request
Object URI is to include a cryptographic random value of 128bit
or more at the time of the writing of this specification.

Point 3: (e) trust between the authorization server and the TFP

Ben’s point is that TFP has to be trusted by Authz Server as well. (That’s implicit since Authz Server is part of the Trust Framework but we probably need to be explicit here.) In addition, (b) sited here is wrong. I propose the change to:

(e) When a third party, such as a Trust Framework Provider (TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object, the same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST know out-of-band that the Client utilizes the Trust Framework Operator and the Authorization Server MUST be a member of that trust framework so that it can trust the TFP.

[Nat Sakimura]

Fixes #94 BK Comments 10.2

→ <<cset 65729b49385c>>

[Nat Sakimura]

Fixes #94 - additional comments

→ <<cset f3539e29cccd>>

[Nat Sakimura]

Fixes #94 - spelling correction

→ <<cset fbcc7478df13>>