[Openid-specs-ab] Starting SIOP draft discussion

Mon May 25 22:58:15 UTC 2020

Interesting. I will look into it. Thanks!

On Tue, May 26, 2020 at 12:11 AM Tom Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> here is a proposal that i made to Kantara HIAWG and to the HEART WGs. This
> has some unique features that are needed in healthcare and may not be
> universally required. I have variously called this an ID token and an AZ
> code. Not sure which applies, but it is NOT a Bearer token. It is generated
> by a user's portable device. Note that in health care, each RP can also be
> an IdP and switches dynamically between the roles. There is a patient id
> (called a record locator) which is common to the two roles. In other
> countries this would be called a national health care ID.
> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
> there is the user agent which is also an IdP and runs on  a user's
> portable device. It generates the above token.
> https://wiki.idesg.org/wiki/index.php/Phone_as_Health_Care_Credential
>
> Peace ..tom
>
>
> On Mon, May 25, 2020 at 6:54 AM Tobias Looker via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Hi all,
>>
>> Firstly this is really interesting work so thank you!
>>
>> I have a few queries about this flow, in particular I don't see how the
>> SIOP has any reliable means to authenticate presentation of obtained
>> assertions from CP's back to RP's? This all appears to hang on a quite
>> specific use of a pre-allocated subject identifier by the RP, that also
>> looks like it would result in the subject being correlated across different
>> CP's? It also appears to constrain the model to requiring just in time
>> issuance or contacting the required CP's on every request from an RP?
>>
>> I'd like to propose a bit of an expansion of this work to deal with what
>> we have been calling `client bound end-user assertions`, essentially
>> enabling the end-user assertions that are obtained in conventional OIDC
>> flows to be bound to the requesting client using public/private key pairs
>> rather than being bearer in nature.
>>
>> See the following link which is a draft spec that aims to document some
>> of the thoughts we have had around this topic. (For those who have seen the
>> document before, it has been significantly revised in the last day or so).
>>
>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>>
>> The high level goals of the draft are the following
>> - Define a way to obtain an end-user assertion that is bound to the
>> client that requested it, in an authenticatable way (e.g using
>> public/private key pairs).
>> - Define how emerging standards like decentralized identifiers could be
>> layered into the flow.
>> - Define a way to request the format of the resulting assertion, leaving
>> room for emerging assertion formats like verifiable credentials.
>>
>> How I see this work relating to SIOP is the assertions obtained by an
>> SIOP from a CP could use this binding mechanism and the binding mechanism
>> could then be exercised on a SIOP response when presenting an assertion
>> from a CP to an RP.
>>
>> Nat, I believe much of what we are suggesting in our draft is inline with
>> the presentation you referred to in your last email that you gave at
>> identiverse last year?
>>
>> Thanks,
>> [image: Mattr website] <https://mattr.global>
>> *Tobias Looker*
>> Mattr
>> +64 (0) 27 378 0461
>> tobias.looker at mattr.global
>> [image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
>> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
>> <https://twitter.com/mattrglobal> [image: Mattr on Github]
>> <https://github.com/mattrglobal>
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me
>> immediately, destroy it, and do not copy or use any part of this
>> communication or disclose anything about it. Thank you. Please note that
>> this communication does not designate an information system for the
>> purposes of the Electronic Transactions Act 2002.
>>
>>
>> On Mon, May 25, 2020 at 6:47 PM Nat Sakimura via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> Hi Tom,
>>>
>>> Is there a documentation on your implementation on the changes that you
>>> made.
>>> That looks quite interesting to me and sounds pretty much in the same
>>> direction as my talk in Identiverse last year.
>>>
>>> Best,
>>>
>>> Nat Sakimura
>>>
>>> On Mon, May 25, 2020 at 1:53 AM Tom Jones via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> I do have a sub that could be a did, but that is not a requirement.
>>>> i use a jwk(s) to allow for old/new key presentation for roll-over.
>>>> i rely on a binding that is essential a verifiable credential.
>>>> My design is specifically build to support IAL2 and AAL2 so there are
>>>> several bindings (VCs), one for each critical attribute.
>>>> One of the bindings to get AAL2 is a software statement and an
>>>> assertion of authentication environment that is signed by the key in the
>>>> software statement.
>>>> That is how i get around the security issues you raised in a previous
>>>> email,
>>>> Peace ..tom
>>>>
>>>>
>>>> On Sun, May 24, 2020 at 8:55 AM Torsten Lodderstedt <
>>>> torsten at lodderstedt.net> wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 23. May 2020, at 03:08, Tom Jones via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>> >
>>>>> > 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 think key roll-over is an important capability.
>>>>>
>>>>> How do you bind the ID to the keys? Do you rely on DIDs?
>>>>>
>>>>> > 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
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>
>> _______________________________________________
>> 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/20200526/c38e3807/attachment.html>