[Openid-specs-ab] [EXTERNAL] Re: Starting SIOP draft discussion

Mon May 25 04:25:54 UTC 2020

Hi Pam and Torsten,

Edmund and I have started to look at the draft last week.
Torsten's got some good points on the key roll-over though I need to think
over them a bit more, especially on the privacy side.
The current way in the SIOP is completely self-contained and the privacy
impact is minimal so I have to think about the change in the impact.

For custom schema: I am in the opinion that it should be replaced by
deep-links from which the app or web can be invoked.
This will be a breaking change for the current SIOP spec, but for good, I
think. It will be much closer to the normal OP then.
For avoiding the Nascar, Kim was mentioning that browsers should support an
extra header to indicate SIOP URL.
I am wondering if WebPayment API etc. can also help.

Best,

Nat

On Mon, May 25, 2020 at 12:47 AM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Pam,
>
> thanks for sharing this draft with us. It’s good to see convergence
> between the two camps.
>
> I’ve got a couple of questions/comments:
> - The draft describes how to use a wallet to login into a DID-aware RP. In
> my opinion, this draft introduces a OIDC-based alternative to
> FIDO2/WebAuthn. What do you think is the advantage of using OIDC instead of
> WebAuthn for exposing this capability? Providing the RP with end-user
> claims along with the DID would be one compelling reason in my opinion. Are
> there any plans to extend the draft in that direction?
> - As far as I understand the ultimate check of the ID Token signature is
> conducted using the key in the DID document. Why is there a need to convey
> the JWKS in sub_jwks. Is this “just” to conform to the SIOP spec? Just
> relying on the DID as user id would allow to benefit from the built-in key
> rollover capabilities of DIDs.
> - I think the request to the wallet could be relayed from one device to
> another device, which an attacker could utilise to trick the victim into
> releasing a valid ID token that the attacker then can use to impersonate
> the victim at the RP. The main reason for this vulnerability is use of the
> custom scheme in the redirect URI, which isn’t bound to a certain OP
> residing on a certain device. RPs residing on a “real” URL could prevent
> this, RPs using custom schemes on the way back cannot.
> - the draft recommends the form post mode for delivering the response to
> the RP (e.g. to prevent token leakage). I’m not a web browser expert, but I
> don’t see how an app-based wallet could perform a OIDC
> response_mode=form_post. Don’t such apps typically do a traditional
> redirect and the OS then kicks in and load the target in the system browser
> or activate another app?
>
> best regards,
> Torsten.
>
> > On 22. May 2020, at 20:46, Pamela Dingle via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >
> > Hey all,
> >
> > DIF has written a decentralized identity draft profile for OpenID
> Connect self-issued provider.   The draft link is below, it needs review by
> this community and I hope we can find a converged path where we either move
> that profile to OIDF for ratification or have some kind of formal liaison
> so that both communities can easily work together.  Please note, this draft
> was not developed in the blockchain vacuum, I believe various of you have
> been consulted over time so hopefully when you read this you will see this
> as a reasonable initial attempt.
> >
> > The draft is here:  https://identity.foundation/did-siop/
> >
> > I think both Nat and Mike have the cross-foundational experience to make
> a recommendation on a good path forward - perhaps a joint meeting to review?
> >
> > Thanks,
> >
> > Pam
> > From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
> behalf of George Fletcher via Openid-specs-ab <
> openid-specs-ab at lists.openid.net>
> > Sent: Friday, May 22, 2020 11:26 AM
> > To: Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> > Cc: George Fletcher <gffletch at aol.com>
> > Subject: [EXTERNAL] Re: [Openid-specs-ab] Starting SIOP draft discussion
> >
> > I don't have any direct comments to these points other than to say that
> the topic of spinning out the SIOP work into a new document and revising it
> came up in the OpenID Connect working group meeting this past Thursday.
> >
> > Topics discussed included making the 'sub' claim not tied to the public
> key and possibly using a DID-like identifier. Or at least allowing a DID as
> the 'sub' claim for those wanting to use SIOP with self-sovereign identity
> use cases.
> >
> > Personally, I'm in favor of making SIOP real for today's use cases :)
> >
> > Thanks,
> > George
> >
> > On 5/21/20 4:25 AM, Nat Sakimura via Openid-specs-ab 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.
> >>
> >> Discussion
> >> 1. What should be the aud of the CP returned JWT?
> >>
> >> Please chime into this thread.
> >> Perhaps I should create an issue in the tracker...
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Openid-specs-ab mailing list
> >>
> >> Openid-specs-ab at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> 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/e3c48dbc/attachment.html>