<div dir="auto"><div>I object to the whole idea of the op and RP conspiracy about my data.</div><div><br></div><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 10, 2025, 9:52 AM Mischa Salle <<a href="mailto:msalle@nikhef.nl">msalle@nikhef.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I think the use-case is RPs that don't need a sub claim, and that is<br>
something that would typically be known between the RP and the OP (the<br>
OP would probably know a certain RP doesn't need it, and the RP would<br>
know that too).<br>
Ideally not sending any sub would solve the same use-case I would think.<br>
<br>
Best,<br>
Mischa<br>
<br>
On Wed, Apr 09, 2025 at 06:02:08AM +0900, Nat Sakimura via Openid-specs-ab wrote:<br>
> You mean, this additional text is a bad idea?<br>
> It may be so, though this seems to be the result of the previous<br>
> conversation.<br>
> I had a bit of doubt on it, so it is not included in the current draft.<br>
> I agree that this should be the user's choice, in principle.<br>
> <br>
> The rationale for including such text is that RP has no way of knowing that<br>
> the identifier is ephemeral otherwise. We could create a new response<br>
> parameter or even introduce a structure to the `sub` value, but the legacy<br>
> RP has no way of telling it anyway and may accumulate unnecessary accounts.<br>
> <br>
> Best,<br>
> <br>
> Nat<br>
> <br>
> 2025年4月9日(水) 1:36 Tom Jones via Openid-specs-ab <<br>
> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>>:<br>
> <br>
> > This proposal on ephemeral ID sounds like a really bad idea from the POV<br>
> > of the user. Things like ephemeral ID should be under the user's control,<br>
> > not the party trying to ID the user.<br>
> ><br>
> > Peace ..tom jones<br>
> ><br>
> ><br>
> > On Mon, Apr 7, 2025 at 2:47 PM Nat Sakimura via Openid-specs-ab <<br>
> > <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> ><br>
> >> After a loooong lapse, here is the ephemeral subject identifier draft.<br>
> >><br>
> >> Maybe<br>
> >><br>
> >> * OP MUST NOT send an ephemeral subject identifier unless it was<br>
> >> requested by the RP using dynamic client registration or some other manner.<br>
> >><br>
> >> Need to be added.<br>
> >><br>
> >><br>
> >> On Fri, Jun 21, 2019 at 2:19 AM Torsten Lodderstedt via Openid-specs-ab <<br>
> >> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> >><br>
> >>> Hi,<br>
> >>><br>
> >>> your proposal sounds reasonable to me. Note: „explicitly asking“ may<br>
> >>> also mean bespoken or profile specific. Not everybody uses dynamic client<br>
> >>> registration.<br>
> >>><br>
> >>> best regards,<br>
> >>> Torsten.<br>
> >>><br>
> >>> > Am 11.06.2019 um 14:46 schrieb Davide Vaghetti <<br>
> >>> <a href="mailto:davide.vaghetti@garr.it" target="_blank" rel="noreferrer">davide.vaghetti@garr.it</a>>:<br>
> >>> ><br>
> >>> > Hi Torsten,<br>
> >>> ><br>
> >>> > thanks for further clarifying the use case you have in mind and sorry<br>
> >>> to<br>
> >>> > come back so late. Let me add some comments.<br>
> >>> ><br>
> >>> >> On 04/06/19 19:07, Torsten Lodderstedt wrote:<br>
> >>> >> Hi Davide,<br>
> >>> >><br>
> >>> >>> On 31. May 2019, at 09:45, Davide Vaghetti <<a href="mailto:davide.vaghetti@garr.it" target="_blank" rel="noreferrer">davide.vaghetti@garr.it</a>><br>
> >>> wrote:<br>
> >>> >>><br>
> >>> >>> Hi Mike,<br>
> >>> >>><br>
> >>> >>>> On 31/05/19 01:42, Mike Jones wrote:<br>
> >>> >>>> Actually, in my experience, most OPs do support configuration<br>
> >>> metadata. (You can see that most certified OPs have an entry in the<br>
> >>> "Config OP" column at <a href="https://openid.net/certification/#OPs" rel="noreferrer noreferrer" target="_blank">https://openid.net/certification/#OPs</a>.) I think<br>
> >>> it's reasonable to require it for this case.<br>
> >>> >>><br>
> >>> >>> Yes, you are right.<br>
> >>> >>><br>
> >>> >>>><br>
> >>> >>>> For those that don't support Dynamic Client Registration, they<br>
> >>> instead will typically have a way of configuring all of the Client<br>
> >>> parameters in the OP's management console. So it's not clear to me that we<br>
> >>> should add anything to the protocol flows to work around the fact that some<br>
> >>> participants won't support Dynamic Client Registration.<br>
> >>> >>><br>
> >>> >>> Probably I shifted the focus on the less important aspect, the client<br>
> >>> >>> configuration, instead of concentrating on the issue raised by<br>
> >>> Torsten,<br>
> >>> >>> which, in my understanding, is:<br>
> >>> >>><br>
> >>> >>> a client can or cannot require a specific subject_type, but no matter<br>
> >>> >>> what it is confident to receive a stable `sub` because the core spec<br>
> >>> is<br>
> >>> >>> saying so.<br>
> >>> >>><br>
> >>> >>> The would-be "openid-transient-id-spec" would change the stability<br>
> >>> >>> quality of the `sub` claim. So maybe, along with the new subject<br>
> >>> type to<br>
> >>> >>> use in configuration, which I proposed, it is not a bad idea to also<br>
> >>> add<br>
> >>> >>> a claim to signal it in the ID token.<br>
> >>> >><br>
> >>> >> The RP somehow needs to determine whether the sub is ephemeral or<br>
> >>> not. In some scenarios, this might be possible based on the OpenID profile<br>
> >>> used or the particular deployment. Or the OP publishes the supported<br>
> >>> subject types in the openid-configration and ONLY supports ephemeral subs.<br>
> >>> I think in all other cases, there is no other way than the OP indicating<br>
> >>> the sub type to the RP on the level of the individual ID token and User<br>
> >>> Info response.<br>
> >>> ><br>
> >>> > The unwritten assumption above is that the RP is NOT asking explicitly<br>
> >>> > for the not-yet-existing ephemeral subject type. That's why, as you<br>
> >>> > write, it'd have to determine what kind of subject type is used in the<br>
> >>> > ID token.<br>
> >>> ><br>
> >>> > A simple rule to avoid any confusion could be that the OP MUST NOT<br>
> >>> > release an ephemeral subject type unless explicitly asked by the RP in<br>
> >>> > the Dynamic Client Registration, as Mike is saying.<br>
> >>> ><br>
> >>> > Though, IMHO I think there might be scenarios where you cannot always<br>
> >>> > rely on the awareness of the RP, for example when the original RP<br>
> >>> passes<br>
> >>> > the ID token to another RP (which by itself might not be a great choice<br>
> >>> > anyway..).<br>
> >>> ><br>
> >>> > What do you guys think?<br>
> >>> ><br>
> >>> > Thanks,<br>
> >>> > Davide<br>
> >>> ><br>
> >>> ><br>
> >>> >><br>
> >>> >>><br>
> >>> >>> The additional claim could be consumed by the client libraries or<br>
> >>> just<br>
> >>> >>> ignored, but it would be available for the upper application layer<br>
> >>> that<br>
> >>> >>> would be aware of the ephemeral nature of the `sub`.<br>
> >>> >>><br>
> >>> >>> Cheers,<br>
> >>> >>> Davide<br>
> >>> >><br>
> >>> >> best regards,<br>
> >>> >> Torsten.<br>
> >>> >><br>
> >>> >>><br>
> >>> >>><br>
> >>> >>><br>
> >>> >>>><br>
> >>> >>>> -- Mike<br>
> >>> >>>><br>
> >>> >>>> -----Original Message-----<br>
> >>> >>>> From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab-bounces@lists.openid.net</a>><br>
> >>> On Behalf Of Davide Vaghetti via Openid-specs-ab<br>
> >>> >>>> Sent: Thursday, May 30, 2019 8:08 AM<br>
> >>> >>>> To: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank" rel="noreferrer">torsten@lodderstedt.net</a>><br>
> >>> >>>> Cc: Davide Vaghetti <<a href="mailto:davide.vaghetti@garr.it" target="_blank" rel="noreferrer">davide.vaghetti@garr.it</a>>; Artifact<br>
> >>> Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>><br>
> >>> >>>> Subject: Re: [Openid-specs-ab] Spec Call Notes 9-May-19<br>
> >>> >>>><br>
> >>> >>>> Hi Torsten,<br>
> >>> >>>><br>
> >>> >>>>> On 30/05/19 16:43, Torsten Lodderstedt wrote:<br>
> >>> >>>>> Hi Davide,<br>
> >>> >>>>><br>
> >>> >>>>> thanks for the write up. I buy into it since I faced such use<br>
> >>> cases in the past.<br>
> >>> >>>>><br>
> >>> >>>>> I’m not quite sure whether it is sufficient to just add another<br>
> >>> subject type value to the subject_types_supported element in the<br>
> >>> openid-configuration since this new subject type significantly changes the<br>
> >>> characteristics of the sub Claim.<br>
> >>> >>>>><br>
> >>> >>>>> Today, a RP can ignore the subject type simply because all sub<br>
> >>> Claim values are supposed to be stable and immutable over multiple OpenID<br>
> >>> Connect transactions. This means the RP can rely on the sub Claim for<br>
> >>> recognising a returning user no matter whether it is a public or pairwise<br>
> >>> id.<br>
> >>> >>>><br>
> >>> >>>> Good point!<br>
> >>> >>>><br>
> >>> >>>> An ephemeral sub value (intentionally) works differently. I feel<br>
> >>> the OP should tell the RP that the sub is ephemeral so the RP knows, it<br>
> >>> cannot establish an id federation. An additional claim “sub_type” in ID<br>
> >>> token or user info response would suffice.<br>
> >>> >>>><br>
> >>> >>>> Now that you say it, I'm also thinking about all the use cases<br>
> >>> where discovery and client registration are not used at all, that happens<br>
> >>> to be the striking majority AFAIK ;-) In those cases it would be just<br>
> >>> impossible to signal that the `sub` is neither public nor pairwise.<br>
> >>> >>>><br>
> >>> >>>> So, to sum up, we could just define a subject type for discovery<br>
> >>> and registration, but also make it explicit adding a subject type claim in<br>
> >>> the ID_token or the user info endpoint --- though I'd recommend passing it<br>
> >>> directly in the ID token. How do you see it?<br>
> >>> >>>><br>
> >>> >>>> Thanks a lot for the feedback.<br>
> >>> >>>><br>
> >>> >>>> Cheers,<br>
> >>> >>>> Davide<br>
> >>> >>>><br>
> >>> >>>>><br>
> >>> >>>>> best regards,<br>
> >>> >>>>> Torsten.<br>
> >>> >>>>><br>
> >>> >>>>><br>
> >>> >>>>>> On 30. May 2019, at 06:59, Davide Vaghetti via Openid-specs-ab <<br>
> >>> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> >>> >>>>>><br>
> >>> >>>>>> Hi,<br>
> >>> >>>>>><br>
> >>> >>>>>> on the point below:<br>
> >>> >>>>>><br>
> >>> >>>>>>> Transient Subject Identifier Type<br>
> >>> >>>>>>><br>
> >>> >>>>>>> At IIW, Davide Vaghetti talked about the need for a<br>
> >>> >>>>>>> transient subject_type value, similar to that in SAML<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Mike and John encouraged him to write a specification<br>
> >>> >>>>>>> for it<br>
> >>> >>>>>><br>
> >>> >>>>>> ... this is what I've come up with:<br>
> >>> >>>>>><br>
> >>> >>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgis" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgis</a><br>
> >>> >>>>>> <a href="http://t.github.com" rel="noreferrer noreferrer" target="_blank">t.github.com</a><br>
> >>> %2Fdaserzw%2F813023b4e1c04d09beb732ef00d7c9e9&data=02<br>
> >>> >>>>>> %7C01%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e510a<br>
> >>> >>>>>><br>
> >>> e85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257157991434&a<br>
> >>> >>>>>><br>
> >>> mp;sdata=pEBD6u1kkuRLvyjUQe4%2BU7gFfqkne4pkPcB1MLX%2Fzfw%3D&reser<br>
> >>> >>>>>> ved=0<br>
> >>> >>>>>><br>
> >>> >>>>>> Cheers,<br>
> >>> >>>>>> Davide<br>
> >>> >>>>>><br>
> >>> >>>>>>> On 09/05/19 17:19, Mike Jones via Openid-specs-ab wrote:<br>
> >>> >>>>>>> Spec Call Notes 9-May-19<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Mike Jones<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Roland Hedberg<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Brian Campbell<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Torsten Lodderstedt<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Bjorn Hjelm<br>
> >>> >>>>>>><br>
> >>> >>>>>>> George Fletcher<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Tom Jones<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> OpenID Certification<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Roland created certification tests for Session,<br>
> >>> >>>>>>> Front-Channel, and Back-Channel, which are now being tested<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Filip Skokan provided a lot of early feedback on the<br>
> >>> >>>>>>> OP tests<br>
> >>> >>>>>>><br>
> >>> >>>>>>> We now need instructions for testing so others can<br>
> >>> do<br>
> >>> >>>>>>> so<br>
> >>> >>>>>>><br>
> >>> >>>>>>> It seems that there will need to be<br>
> >>> some<br>
> >>> >>>>>>> browser-specific instructions in some cases<br>
> >>> >>>>>>><br>
> >>> >>>>>>> There are RP logout tests also but they haven't been<br>
> >>> >>>>>>> tested yet by others than Roland<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Authentication Failed Error Code Draft<br>
> >>> >>>>>>><br>
> >>> >>>>>>> This is issue #1029<br>
> >>> >>>>>>><br>
> >>> >>>>>>> The error code is now<br>
> >>> >>>>>>> unmet_authentication_requirements<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Torsten submitted and Mike will publish the working<br>
> >>> >>>>>>> group draft<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> OpenID Connect for Identity Proofing<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Another new draft was published at<br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fop" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fop</a><br>
> >>> >>>>>>> <a href="http://enid.net" rel="noreferrer noreferrer" target="_blank">enid.net</a><br>
> >>> %2Fspecs%2Fopenid-connect-4-identity-assurance.html&data<br>
> >>> >>>>>>> =02%7C01%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e<br>
> >>> >>>>>>><br>
> >>> 510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257157991<br>
> >>> >>>>>>><br>
> >>> 434&sdata=DHoH3yut5W%2Bkhz48kXr7oAe%2FxldYrBj32kG0SpWWhJY%3D&<br>
> >>> >>>>>>> ;reserved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Torsten led a discussion at IIW<br>
> >>> >>>>>>><br>
> >>> >>>>>>> A lot of good feedback was received, including on<br>
> >>> >>>>>>> requirements for other jurisdictions<br>
> >>> >>>>>>><br>
> >>> >>>>>>> It was pointed out that some proofs will require<br>
> >>> >>>>>>> multiple documents<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Torsten is working on updated syntax<br>
> >>> for<br>
> >>> >>>>>>> that<br>
> >>> >>>>>>><br>
> >>> >>>>>>> See issue #1082: Support for multiple<br>
> >>> >>>>>>> proof sources<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Reviews are solicited<br>
> >>> >>>>>>><br>
> >>> >>>>>>> We agreed that Torsten should present this during EIC<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> EIC Next Week<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Roland, Torsten, Bjorn, George, and Mike will be at<br>
> >>> >>>>>>> EIC next week<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Distinguishing first and third party cookies<br>
> >>> >>>>>>><br>
> >>> >>>>>>> George let us know that there's a spec that adds the<br>
> >>> >>>>>>> same-site qualifier to cookies<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto</a><br>
> >>> >>>>>>> <a href="http://ols.ietf.org" rel="noreferrer noreferrer" target="_blank">ols.ietf.org</a><br>
> >>> %2Fhtml%2Fdraft-west-cookie-incrementalism-00&data=0<br>
> >>> >>>>>>> 2%7C01%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e51<br>
> >>> >>>>>>><br>
> >>> 0ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63694825715800143<br>
> >>> >>>>>>><br>
> >>> 1&sdata=OAxFUV3oCfI1JtT2XDJzBrNt1UtTuvYHfIhUWXZ2TnE%3D&reser<br>
> >>> >>>>>>> ved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Values are none, strict, and lax<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Also see<br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwe" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwe</a><br>
> >>> >>>>>>> <a href="http://b.dev" rel="noreferrer noreferrer" target="_blank">b.dev</a><br>
> >>> %2Fsamesite-cookies-explained%2F&data=02%7C01%7CMichael.Jon<br>
> >>> >>>>>>> es%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e510ae85%7C72f988bf86f1<br>
> >>> >>>>>>><br>
> >>> 41af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&sdata=zqrTFtt6<br>
> >>> >>>>>>> ym7EMp%2FV3sIIyVzobGdI%2FKyFJqDONWPIMCo%3D&reserved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>>> and<br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbl" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbl</a><br>
> >>> >>>>>>> <a href="http://og.chromium.org" rel="noreferrer noreferrer" target="_blank">og.chromium.org</a><br>
> >>> %2F2019%2F05%2Fimproving-privacy-and-security-on-web.<br>
> >>> >>>>>>> html&data=02%7C01%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae<br>
> >>> >>>>>>><br>
> >>> 479e023408d6e510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63<br>
> >>> >>>>>>><br>
> >>> 6948257158001431&sdata=uu81%2BjwRSSVeRBRm0jOF5gCCI7aY09DxCGjLWEA<br>
> >>> >>>>>>> TxhQ%3D&reserved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Google is adding support for this to Chrome<br>
> >>> >>>>>>><br>
> >>> >>>>>>> George asked whether this might affect iframe and<br>
> >>> >>>>>>> postMessage communication<br>
> >>> >>>>>>><br>
> >>> >>>>>>> And whether this might affect Session<br>
> >>> >>>>>>> Management<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Open Issues<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbi" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbi</a><br>
> >>> >>>>>>> <a href="http://tbucket.org" rel="noreferrer noreferrer" target="_blank">tbucket.org</a><br>
> >>> %2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dop<br>
> >>> >>>>>>> en&data=02%7C01%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae47<br>
> >>> >>>>>>><br>
> >>> 9e023408d6e510ae85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369<br>
> >>> >>>>>>><br>
> >>> 48257158001431&sdata=HY6kppsUZgnYT9Pi1L2brJafznKTD%2Ffqa8Rl511JF<br>
> >>> >>>>>>> 8Y%3D&reserved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>>> #1083: policy_uri, tos_uri, logo_uri missing in IANA<br>
> >>> >>>>>>> JWT claims registry<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Brian asked whether Nat really meant<br>
> >>> the<br>
> >>> >>>>>>> JWT Claims registry or the AS Metadata registry<br>
> >>> >>>>>>><br>
> >>> >>>>>>> #1081: Need for a persistence user identifier - a<br>
> >>> PUID<br>
> >>> >>>>>>><br>
> >>> >>>>>>> We discussed that change of keys is a<br>
> >>> >>>>>>> change of identity for self-issued<br>
> >>> >>>>>>><br>
> >>> >>>>>>> We discussed the ability to add a "did"<br>
> >>> >>>>>>> claim to the ID Token when it is useful<br>
> >>> >>>>>>><br>
> >>> >>>>>>> We discussed that the "sub" value must<br>
> >>> >>>>>>> not change at key roll-over time<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Transient Subject Identifier Type<br>
> >>> >>>>>>><br>
> >>> >>>>>>> At IIW, Davide Vaghetti talked about the need for a<br>
> >>> >>>>>>> transient subject_type value, similar to that in SAML<br>
> >>> >>>>>>><br>
> >>> >>>>>>> Mike and John encouraged him to write a<br>
> >>> specification<br>
> >>> >>>>>>> for it<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> Next Call<br>
> >>> >>>>>>><br>
> >>> >>>>>>> The May 13th call is cancelled due EIC<br>
> >>> >>>>>>><br>
> >>> >>>>>>> The next call is Thursday, May 23 at 7am Pacific Time<br>
> >>> >>>>>>><br>
> >>> >>>>>>><br>
> >>> >>>>>>> _______________________________________________<br>
> >>> >>>>>>> Openid-specs-ab mailing list<br>
> >>> >>>>>>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> >>> >>>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flis" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flis</a><br>
> >>> >>>>>>> <a href="http://ts.openid.net" rel="noreferrer noreferrer" target="_blank">ts.openid.net</a><br>
> >>> %2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C0<br>
> >>> >>>>>>> 1%7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e510ae85<br>
> >>> >>>>>>><br>
> >>> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&<br>
> >>> >>>>>>><br>
> >>> ;sdata=JP%2Ftb5toYxyiH20Pkislc%2FGJiMQ%2Fvr642cjB9554HmE%3D&rese<br>
> >>> >>>>>>> rved=0<br>
> >>> >>>>>>><br>
> >>> >>>>>><br>
> >>> >>>>>> --<br>
> >>> >>>>>> Davide Vaghetti<br>
> >>> >>>>>> Consortium GARR<br>
> >>> >>>>>> Tel: +390502213158<br>
> >>> >>>>>> Mobile: +393357779542<br>
> >>> >>>>>> Skype: daserzw<br>
> >>> >>>>>><br>
> >>> >>>>>> _______________________________________________<br>
> >>> >>>>>> Openid-specs-ab mailing list<br>
> >>> >>>>>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> >>> >>>>>><br>
> >>> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist</a><br>
> >>> >>>>>> <a href="http://s.openid.net" rel="noreferrer noreferrer" target="_blank">s.openid.net</a><br>
> >>> %2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%<br>
> >>> >>>>>> 7CMichael.Jones%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a><br>
> >>> %7C659ae0bd52ae479e023408d6e510ae85%7C<br>
> >>> >>>>>><br>
> >>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948257158001431&sda<br>
> >>> >>>>>><br>
> >>> ta=JP%2Ftb5toYxyiH20Pkislc%2FGJiMQ%2Fvr642cjB9554HmE%3D&reserved=<br>
> >>> >>>>>> 0<br>
> >>> >>>>><br>
> >>> >>>><br>
> >>> >>>> --<br>
> >>> >>>> Davide Vaghetti<br>
> >>> >>>> Consortium GARR<br>
> >>> >>>> Tel: +390502213158<br>
> >>> >>>> Mobile: +393357779542<br>
> >>> >>>> Skype: daserzw<br>
> >>> >>>><br>
> >>> >>><br>
> >>> >>> --<br>
> >>> >>> Davide Vaghetti<br>
> >>> >>> Consortium GARR<br>
> >>> >>> Tel: +390502213158<br>
> >>> >>> Mobile: +393357779542<br>
> >>> >>> Skype: daserzw<br>
> >>> >>><br>
> >>> >><br>
> >>> ><br>
> >>> > --<br>
> >>> > Davide Vaghetti<br>
> >>> > Consortium GARR<br>
> >>> > Tel: +390502213158<br>
> >>> > Mobile: +393357779542<br>
> >>> > Skype: daserzw<br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> _______________________________________________<br>
> >>> Openid-specs-ab mailing list<br>
> >>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> >>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Nat Sakimura (=nat)<br>
> >> Chairman, OpenID Foundation<br>
> >> <a href="http://nat.sakimura.org/" rel="noreferrer noreferrer" target="_blank">http://nat.sakimura.org/</a><br>
> >> @_nat_en<br>
> >> _______________________________________________<br>
> >> Openid-specs-ab mailing list<br>
> >> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> >> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> >><br>
> > _______________________________________________<br>
> > Openid-specs-ab mailing list<br>
> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> > <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> ><br>
<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
-- <br>
Nikhef Room H231a<br>
Science Park 105 Tel. +31-6-4681 2202<br>
1098 XG Amsterdam Fax +31-20-592 5155<br>
The Netherlands Email <a href="mailto:msalle@nikhef.nl" target="_blank" rel="noreferrer">msalle@nikhef.nl</a><br>
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..<br>
</blockquote></div>