[Openid-specs-ab] Starting SIOP draft discussion

[Tom Jones]

I have built an self-issued plan for health care. I decided it did not have
sense to have a sub that was essentially a key-id and went another route
which i plan to continue.
It uses an ID that supports key roll-over.
I would like to see a group address self-issued, but if there is a
precondition to use the sub as defined in opic, I would not bother.
I have been a member of FAPI and HEART.
I have not joined AB/C as it never seemed in my interest. If self-issued
was started without preconditions i would join.
I would be happy to demonstrate the UX demo i have, or show how it fits
into health care if that would be helpful.
Peace ..tom


On Fri, May 22, 2020 at 12:25 PM Mike Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> FYI, those using the Self-Issued OpenID Provider for DID Auth are using it
> a conforming way.  The “sub” value is the JWK Thumbprint of the public key
> and they add a “did” claim to the ID Token.  No breaking changes are needed.
>
>                                                                      --
> Mike
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of *Pamela Dingle via Openid-specs-ab
> *Sent:* Friday, May 22, 2020 11:46 AM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Pamela Dingle <Pamela.Dingle at microsoft.com>
> *Subject:* Re: [Openid-specs-ab] Starting SIOP draft discussion
>
>
>
> 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7CPamela.Dingle%40microsoft.com%7Cf39bbc422b754749a3b808d7fe7db2d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637257688151453303&sdata=r%2BV7vX58WmLUWqOAyvaLuMEnVVuj4B1OhRPIUFrPRrU%3D&reserved=0>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200522/99b9b16c/attachment.html>