[Openid-specs-ab] Starting SIOP draft discussion

[Nat Sakimura]

Hi Torsten,

Thanks for your comments. My comments inline:

On Mon, May 25, 2020 at 12:18 AM Torsten Lodderstedt <
torsten at lodderstedt.net> wrote:

> Hi Nat,
>
> > On 21. May 2020, at 10:25, Nat Sakimura via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >
> > Hi
> >
> > I and Edmund have been discussing the additional SIOP requirements that
> were agreed to made into an independent document a while ago.
> >
> > Here is what I am thinking right now. Edmund has a draft for new
> "Aggregation Endpoint" of the Claims Providers (CP) that I am hoping that
> he can follow up with.
> >
> >
> >
> > General Flow happens like this.
> >
> > 1. On-Boarding of SIOP to CP
> > 1.1. Dynamic Client Registration of SIOP to CP
> > 1.2. User Authorizes general data access to SIOP.
> > 1.3. SIOP obtains the AT/RT.
> >
> > 2. RP asking for a set of claims
> > 2.1. RP requests the SIOP for a set of claims
> > 2.2. SIOP creates the constrained claims request using AT and uid whose
> value
> >      is the `sub` value that the SIOP uses against the RP and should be
> set as
> > the `sub` value of the aggregation endpoint response (NEW)
> > 2.3. CP returns a JWS signed JWT that contains sub=value(uid) and other
> requested claims in the payload.
> > 2.4. SIOP puts the JWT in the ID Token and responds to the RP.
> > 2.5. RP verifies that the `sub` value of the ID Token is equal to the
> `sub` value in the CP minted JWT,  besides all the verification that is
> required for ID Token.
> >
> > Here are some of the Requirements that follows the above.
> >
> > 1. CP MUST support OAuth Dynamic Client Registration.
> > 2. CP MUST support "aggregation endpoint" that is capable of returning
> constrained JWT with sub=uid.
>
> Is there similarity to the ideas in this ticket?
> https://bitbucket.org/openid/ekyc-ida/issues/1185/just-requesting-minimum-set-of-claims-for
>
>
Yes. The draft (hopefully Edmund can send it in soon) was actually written
around the time of the original ticket.


> >
> > Discussion
> > 1. What should be the aud of the CP returned JWT?
>
> I think it must (at least) contain the RP’s client id (see
> https://openid.net/specs/openid-connect-core-1_0.html#IDToken) otherwise
> the JWT could be replayed with other RPs.
>

The twist is that CP often MUST NOT know who the RP is. This is one of the
privacy requirements.
In a truly dynamic case, we can use an ephemeral identifier except that in
Section 7.2 of OIDC Core, it is defined that

client_idredirect_uri value of the Client.
So, if we provide this to the CP, CP will be able to link the RP, which is
not good.

In a store and use later kind of use-case, it cannot specify the RP to
start with.

Note though, the replay by the SIOP is not an issue really except in the
case where CP wants to charge by dips.
The original use-case of now-defunct `azp` claim is actually this one.
SIOP, in this case, is the `azp`, i.e., constraining the sender instead of
the recipient.


> An interesting question might be how replay on different devices for the
> same RP can be prevented.


It is worth noting that the claims are not providing information about the
authentication event. It is merely providing the information that is known
to the CP at the time of minting the JWT. So, the replay itself is not so
much of an issue as long as it is sender constrained to the user. So, this
issue can be localized to the JWT minted by the SIOP itself, making the
discussion somewhat more scoped and simple. The issue here is that the ID
Token minted by the SIOP is shipped to another device and replayed, right?
I am guessing it is fine as long as the RP properly implements CSRF
protection, is it not?


> The nonce could be sent all the way through to the CP and included in the
> JWT as well. But given the weaknesses around public clients discovered in
> the course of the latest OAuth 2.1/PKCE/nonce discussion on the OAuth list
> I’m not sure whether that’s the best option.
>

There is no public client involved in SIOP. While SIOP may live on a
smartphone, each installation has more than one key-pairs to strongly
authenticate itself to other parties.


>
> Another aspect: As discussed in Miyazaki, the eKCY-IDA request syntax
> could be used to determine a suitable CP (e.g. depending on the trust
> framework the RP asks for). With eKYC-IDA revision -10 the response from
> the SIOP could also contain the same verified claims from different
> sources. I think it’s worth incorporating these ideas/features into the
> SIOP draft.
>

That's where I am going to and intending to leave it blank in the SIOP
Claims Aggregation draft.
N.B. we need SIOP Distributed Claims draft as well, by the way.


> best regards,
> Torsten.
>
> >
> > Please chime into this thread.
> > Perhaps I should create an issue in the tracker...
> >
> > --
> > Nat Sakimura
> > NAT.Consulting LLC
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>

-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200525/004920f1/attachment.html>