- changed title to 5.3.2 (te) Current draft is too specific to SIOP
5.3.2 (te) Current draft is too specific to SIOP
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.
Comments (7)
-
reporter -
reporter - changed status to open
The problem statement is agreed.
-
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. -
reporter 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
andsub
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 theiss
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 theiss
value dynamically, then we have to wait until Claims Endpoint Request and things gets complicated. My suggestion is to assume OPiss
to be static. Then, the OP can prove that it is the entity thatiss
points to at the registration time and have the CP return the value in a parameter likeop_iss
.
-
@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? -
reporter 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 theiss
sub
pair in the ID Token. -
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?
- Log in to comment