[Openid-specs-ab] Spec Call Notes 9-May-19

Tom Jones thomasclinganjones at gmail.com
Tue Jun 4 17:29:50 UTC 2019


This whole thread seems to be missing the main point. The sub can be
invalidated at any time by any party. I found this to be particularly true
with the did from the w3c ccg. It seems that the user can invalidate the
did between the time it is used and the time the transaction is logged. I
suspect that what is needed is some indication of the duration of
applicability of any assertion. Something the the ttl of http but based on
a expiry date-time. That value could be (optionally) inserted into any JSON
object where the parties thought it to be needed.
Peace ..tom


On Tue, Jun 4, 2019 at 10:14 AM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Davide,
>
> > On 31. May 2019, at 09:45, Davide Vaghetti <davide.vaghetti at garr.it>
> wrote:
> >
> > Hi Mike,
> >
> > On 31/05/19 01:42, Mike Jones wrote:
> >> Actually, in my experience, most OPs do support configuration
> metadata.  (You can see that most certified OPs have an entry in the
> "Config OP" column at https://openid.net/certification/#OPs.) I think
> it's reasonable to require it for this case.
> >
> > Yes, you are right.
> >
> >>
> >> For those that don't support Dynamic Client Registration, they instead
> will typically have a way of configuring all of the Client parameters in
> the OP's management console.  So it's not clear to me that we should add
> anything to the protocol flows to work around the fact that some
> participants won't support Dynamic Client Registration.
> >
> > Probably I shifted the focus on the less important aspect, the client
> > configuration, instead of concentrating on the issue raised by Torsten,
> > which, in my understanding, is:
> >
> > a client can or cannot require a specific subject_type, but no matter
> > what it is confident to receive a stable `sub` because the core spec is
> > saying so.
> >
> > The would-be "openid-transient-id-spec" would change the stability
> > quality of the `sub` claim. So maybe, along with the new subject type to
> > use in configuration, which I proposed, it is not a bad idea to also add
> > a claim to signal it in the ID token.
>
> The RP somehow needs to determine whether the sub is ephemeral or not. In
> some scenarios, this might be possible based on the OpenID profile used or
> the particular deployment. Or the OP publishes the supported subject types
> in the openid-configration and ONLY supports ephemeral subs. I think in all
> other cases, there is no other way than the OP indicating the sub type to
> the RP on the level of the individual ID token and User Info response.
>
> >
> > The additional claim could be consumed by the client libraries or just
> > ignored, but it would be available for the upper application layer that
> > would be aware of the ephemeral nature of the `sub`.
> >
> > Cheers,
> > Davide
>
> best regards,
> Torsten.
>
> >
> >
> >
> >>
> >>                              -- Mike
> >>
> >> -----Original Message-----
> >> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On
> Behalf Of Davide Vaghetti via Openid-specs-ab
> >> Sent: Thursday, May 30, 2019 8:08 AM
> >> To: Torsten Lodderstedt <torsten at lodderstedt.net>
> >> Cc: Davide Vaghetti <davide.vaghetti at garr.it>; Artifact
> Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
> >> Subject: Re: [Openid-specs-ab] Spec Call Notes 9-May-19
> >>
> >> Hi Torsten,
> >>
> >> On 30/05/19 16:43, Torsten Lodderstedt wrote:
> >>> Hi Davide,
> >>>
> >>> thanks for the write up. I buy into it since I faced such use cases in
> the past.
> >>>
> >>> I’m not quite sure whether it is sufficient to just add another
> subject type value to the subject_types_supported element in the
> openid-configuration since this new subject type significantly changes the
> characteristics of the sub Claim.
> >>>
> >>> Today, a RP can ignore the subject type simply because all sub Claim
> values are supposed to be stable and immutable over multiple OpenID Connect
> transactions. This means the RP can rely on the sub Claim for recognising a
> returning user no matter whether it is a public or pairwise id.
> >>
> >> Good point!
> >>
> >> An ephemeral sub value (intentionally) works differently. I feel the OP
> should tell the RP that the sub is ephemeral so the RP knows, it cannot
> establish an id federation. An additional claim “sub_type” in ID token or
> user info response would suffice.
> >>
> >> Now that you say it, I'm also thinking about all the use cases where
> discovery and client registration are not used at all, that happens to be
> the striking majority AFAIK ;-) In those cases it would be just impossible
> to signal that the `sub` is neither public nor pairwise.
> >>
> >> So, to sum up, we could just define a subject type for discovery and
> registration, but also make it explicit adding a subject type claim in the
> ID_token or the user info endpoint --- though I'd recommend passing it
> directly in the ID token. How do you see it?
> >>
> >> Thanks a lot for the feedback.
> >>
> >> Cheers,
> >> Davide
> >>
> >>>
> >>> best regards,
> >>> Torsten.
> >>>
> >>>
> >>>> On 30. May 2019, at 06:59, Davide Vaghetti via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> on the point below:
> >>>>
> >>>>> Transient Subject Identifier Type
> >>>>>
> >>>>>             At IIW, Davide Vaghetti talked about the need for a
> >>>>> transient subject_type value, similar to that in SAML
> >>>>>
> >>>>>             Mike and John encouraged him to write a specification
> >>>>> for it
> >>>>
> >>>> ... this is what I've come up with:
> >>>>
> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgis
> >>>> t.github.com%2Fdaserzw%2F813023b4e1c04d09beb732ef00d7c9e9&data=02
> >>>> %7C01%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae479e023408d6e510a
> >>>> e85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257157991434&a
> >>>> mp;sdata=pEBD6u1kkuRLvyjUQe4%2BU7gFfqkne4pkPcB1MLX%2Fzfw%3D&reser
> >>>> ved=0
> >>>>
> >>>> Cheers,
> >>>> Davide
> >>>>
> >>>> On 09/05/19 17:19, Mike Jones via Openid-specs-ab wrote:
> >>>>> Spec Call Notes 9-May-19
> >>>>>
> >>>>>
> >>>>>
> >>>>> Mike Jones
> >>>>>
> >>>>> Roland Hedberg
> >>>>>
> >>>>> Brian Campbell
> >>>>>
> >>>>> Torsten Lodderstedt
> >>>>>
> >>>>> Bjorn Hjelm
> >>>>>
> >>>>> George Fletcher
> >>>>>
> >>>>> Tom Jones
> >>>>>
> >>>>>
> >>>>>
> >>>>> OpenID Certification
> >>>>>
> >>>>>              Roland created certification tests for Session,
> >>>>> Front-Channel, and Back-Channel, which are now being tested
> >>>>>
> >>>>>              Filip Skokan provided a lot of early feedback on the
> >>>>> OP tests
> >>>>>
> >>>>>              We now need instructions for testing so others can do
> >>>>> so
> >>>>>
> >>>>>                           It seems that there will need to be some
> >>>>> browser-specific instructions in some cases
> >>>>>
> >>>>>              There are RP logout tests also but they haven't been
> >>>>> tested yet by others than Roland
> >>>>>
> >>>>>
> >>>>>
> >>>>> Authentication Failed Error Code Draft
> >>>>>
> >>>>>              This is issue #1029
> >>>>>
> >>>>>              The error code is now
> >>>>> unmet_authentication_requirements
> >>>>>
> >>>>>              Torsten submitted and Mike will publish the working
> >>>>> group draft
> >>>>>
> >>>>>
> >>>>>
> >>>>> OpenID Connect for Identity Proofing
> >>>>>
> >>>>>              Another new draft was published at
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fop
> >>>>> enid.net%2Fspecs%2Fopenid-connect-4-identity-assurance.html&data
> >>>>> =02%7C01%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae479e023408d6e
> >>>>> 510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257157991
> >>>>> 434&sdata=DHoH3yut5W%2Bkhz48kXr7oAe%2FxldYrBj32kG0SpWWhJY%3D&amp
> >>>>> ;reserved=0
> >>>>>
> >>>>>              Torsten led a discussion at IIW
> >>>>>
> >>>>>              A lot of good feedback was received, including on
> >>>>> requirements for other jurisdictions
> >>>>>
> >>>>>              It was pointed out that some proofs will require
> >>>>> multiple documents
> >>>>>
> >>>>>                           Torsten is working on updated syntax for
> >>>>> that
> >>>>>
> >>>>>                           See issue #1082: Support for multiple
> >>>>> proof sources
> >>>>>
> >>>>>              Reviews are solicited
> >>>>>
> >>>>>              We agreed that Torsten should present this during EIC
> >>>>>
> >>>>>
> >>>>>
> >>>>> EIC Next Week
> >>>>>
> >>>>>              Roland, Torsten, Bjorn, George, and Mike will be at
> >>>>> EIC next week
> >>>>>
> >>>>>
> >>>>>
> >>>>> Distinguishing first and third party cookies
> >>>>>
> >>>>>              George let us know that there's a spec that adds the
> >>>>> same-site qualifier to cookies
> >>>>>
> >>>>>
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto
> >>>>> ols.ietf.org%2Fhtml%2Fdraft-west-cookie-incrementalism-00&data=0
> >>>>> 2%7C01%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae479e023408d6e51
> >>>>> 0ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63694825715800143
> >>>>> 1&sdata=OAxFUV3oCfI1JtT2XDJzBrNt1UtTuvYHfIhUWXZ2TnE%3D&reser
> >>>>> ved=0
> >>>>>
> >>>>>                           Values are none, strict, and lax
> >>>>>
> >>>>>                           Also see
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwe
> >>>>> b.dev%2Fsamesite-cookies-explained%2F&data=02%7C01%7CMichael.Jon
> >>>>> es%40microsoft.com%7C659ae0bd52ae479e023408d6e510ae85%7C72f988bf86f1
> >>>>> 41af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&sdata=zqrTFtt6
> >>>>> ym7EMp%2FV3sIIyVzobGdI%2FKyFJqDONWPIMCo%3D&reserved=0
> >>>>>
> >>>>>                           and
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbl
> >>>>> og.chromium.org%2F2019%2F05%2Fimproving-privacy-and-security-on-web.
> >>>>> html&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae
> >>>>> 479e023408d6e510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> >>>>> 6948257158001431&sdata=uu81%2BjwRSSVeRBRm0jOF5gCCI7aY09DxCGjLWEA
> >>>>> TxhQ%3D&reserved=0
> >>>>>
> >>>>>              Google is adding support for this to Chrome
> >>>>>
> >>>>>              George asked whether this might affect iframe and
> >>>>> postMessage communication
> >>>>>
> >>>>>                           And whether this might affect Session
> >>>>> Management
> >>>>>
> >>>>>
> >>>>>
> >>>>> Open Issues
> >>>>>
> >>>>>
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbi
> >>>>> tbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dop
> >>>>> en&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae47
> >>>>> 9e023408d6e510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369
> >>>>> 48257158001431&sdata=HY6kppsUZgnYT9Pi1L2brJafznKTD%2Ffqa8Rl511JF
> >>>>> 8Y%3D&reserved=0
> >>>>>
> >>>>>              #1083: policy_uri, tos_uri, logo_uri missing in IANA
> >>>>> JWT claims registry
> >>>>>
> >>>>>                           Brian asked whether Nat really meant the
> >>>>> JWT Claims registry or the AS Metadata registry
> >>>>>
> >>>>>              #1081: Need for a persistence user identifier - a PUID
> >>>>>
> >>>>>                           We discussed that change of keys is a
> >>>>> change of identity for self-issued
> >>>>>
> >>>>>                           We discussed the ability to add a "did"
> >>>>> claim to the ID Token when it is useful
> >>>>>
> >>>>>                           We discussed that the "sub" value must
> >>>>> not change at key roll-over time
> >>>>>
> >>>>>
> >>>>>
> >>>>> Transient Subject Identifier Type
> >>>>>
> >>>>>              At IIW, Davide Vaghetti talked about the need for a
> >>>>> transient subject_type value, similar to that in SAML
> >>>>>
> >>>>>              Mike and John encouraged him to write a specification
> >>>>> for it
> >>>>>
> >>>>>
> >>>>>
> >>>>> Next Call
> >>>>>
> >>>>>              The May 13th call is cancelled due EIC
> >>>>>
> >>>>>              The next call is Thursday, May 23 at 7am Pacific Time
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Openid-specs-ab mailing list
> >>>>> Openid-specs-ab at lists.openid.net
> >>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flis
> >>>>> ts.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C0
> >>>>> 1%7CMichael.Jones%40microsoft.com%7C659ae0bd52ae479e023408d6e510ae85
> >>>>> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&amp
> >>>>> ;sdata=JP%2Ftb5toYxyiH20Pkislc%2FGJiMQ%2Fvr642cjB9554HmE%3D&rese
> >>>>> rved=0
> >>>>>
> >>>>
> >>>> --
> >>>> Davide Vaghetti
> >>>> Consortium GARR
> >>>> Tel: +390502213158
> >>>> Mobile: +393357779542
> >>>> Skype: daserzw
> >>>>
> >>>> _______________________________________________
> >>>> Openid-specs-ab mailing list
> >>>> Openid-specs-ab at lists.openid.net
> >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >>>> s.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%
> >>>> 7CMichael.Jones%40microsoft.com%7C659ae0bd52ae479e023408d6e510ae85%7C
> >>>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&sda
> >>>> ta=JP%2Ftb5toYxyiH20Pkislc%2FGJiMQ%2Fvr642cjB9554HmE%3D&reserved=
> >>>> 0
> >>>
> >>
> >> --
> >> Davide Vaghetti
> >> Consortium GARR
> >> Tel: +390502213158
> >> Mobile: +393357779542
> >> Skype: daserzw
> >>
> >
> > --
> > Davide Vaghetti
> > Consortium GARR
> > Tel: +390502213158
> > Mobile: +393357779542
> > Skype: daserzw
> >
>
> _______________________________________________
> 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/20190604/b0f7a20a/attachment-0001.html>


More information about the Openid-specs-ab mailing list