5.3.2 (te) Current draft is too specific to SIOP

[Nat Sakimura]

Claims aggregation should be useable by a normal OP as well.

Currently, uid in 5.3.2 is defined specifically for SIOP. For a normal OP, it can be any string. For DID, it should again be a string conforming to DID spec. We should make uid a generic string. Key materials if needed should be conveyed separately. In the case of SIOP, this string just happens to be what is defined in the current text.

[Nat Sakimura]

The problem statement is agreed.

[Tobias Looker]

I agree with this, taking an even more generalized view uid in section 5.3.2 to me represents a way to reflect the role of the the intermediary provider (often called the holder) authority to be presenting claims on behalf of the claims provider.

[Nat Sakimura]

Thinking further, I came to the conclusion that including uid (that represent the combination of the issuer and the user) at this point is way too early. In many cases, the user identifier (sub value) is indeterminate at this point. Typically, we have to wait until at least to the first request the RP makes to the OP (Holder). See #1233.

On the other hand, for a normal OP, the user identifier to the RP is in fact the combination of the iss and sub value. So, the OP (Holder) needs to demonstrate that it is the entity that controls the keys corresponding to one of the key in the .well-known/jwks.json. If the iss can be assumed to be constant, then we could do it at the registration or set-up phase (5.3). If we want to change the iss value dynamically, then we have to wait until Claims Endpoint Request and things gets complicated. My suggestion is to assume OP iss to be static. Then, the OP can prove that it is the entity that iss points to at the registration time and have the CP return the value in a parameter like op_iss.

‌

[Torsten Lodderstedt]

@Nat Sakimura

As far as I understand the draft, uid is the user identifier with the intermediary OP and is used to tie the claims issued by the CP to this identifier. Can you please explain the purpose of this mechanism?

[Nat Sakimura]

uid is the mechanism to bind the authentication response to the RP to the signed claim set that the CP returns. That way, RP can verify that it the claim set issued by the CP is indeed about the subject identified by the iss sub pair in the ID Token.

[Torsten Lodderstedt]

The CP does not know anything about uid, it is supposed to put in its claims set whatever the OP passes as uid parameter value. I don’t see how this establishes a binding on the identity/ user account level.

What attacks do you wanna prevent with this mechanism?