[Openid-specs-ab] Ephemeral Identifier

Tom Jones thomasclinganjones at gmail.com
Thu Apr 10 19:02:35 UTC 2025 

I object to the whole idea of the op and RP conspiracy about my data.

thx ..Tom (mobile)

On Thu, Apr 10, 2025, 9:52 AM Mischa Salle <msalle at nikhef.nl> wrote:

> Hi all,
>
> I think the use-case is RPs that don't need a sub claim, and that is
> something that would typically be known between the RP and the OP (the
> OP would probably know a certain RP doesn't need it, and the RP would
> know that too).
> Ideally not sending any sub would solve the same use-case I would think.
>
> Best,
> Mischa
>
> On Wed, Apr 09, 2025 at 06:02:08AM +0900, Nat Sakimura via Openid-specs-ab
> wrote:
> > You mean, this additional text is a bad idea?
> > It may be so, though this seems to be the result of the previous
> > conversation.
> > I had a bit of doubt on it, so it is not included in the current draft.
> > I agree that this should be the user's choice, in principle.
> >
> > The rationale for including such text is that RP has no way of knowing
> that
> > the identifier is ephemeral otherwise. We could create a new response
> > parameter or even introduce a structure to the `sub` value, but the
> legacy
> > RP has no way of telling it anyway and may accumulate unnecessary
> accounts.
> >
> > Best,
> >
> > Nat
> >
> > 2025年4月9日(水) 1:36 Tom Jones via Openid-specs-ab <
> > openid-specs-ab at lists.openid.net>:
> >
> > > This proposal on ephemeral ID sounds like a really bad idea from the
> POV
> > > of the user.  Things like ephemeral ID should be under the user's
> control,
> > > not the party trying to ID the user.
> > >
> > > Peace ..tom jones
> > >
> > >
> > > On Mon, Apr 7, 2025 at 2:47 PM Nat Sakimura via Openid-specs-ab <
> > > openid-specs-ab at lists.openid.net> wrote:
> > >
> > >> After a loooong lapse, here is the ephemeral subject identifier draft.
> > >>
> > >> Maybe
> > >>
> > >> * OP MUST NOT send an ephemeral subject identifier unless it was
> > >> requested by the RP using dynamic client registration or some other
> manner.
> > >>
> > >> Need to be added.
> > >>
> > >>
> > >> On Fri, Jun 21, 2019 at 2:19 AM Torsten Lodderstedt via
> Openid-specs-ab <
> > >> openid-specs-ab at lists.openid.net> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> your proposal  sounds reasonable to me. Note: „explicitly asking“ may
> > >>> also mean bespoken or profile specific. Not everybody uses dynamic
> client
> > >>> registration.
> > >>>
> > >>> best regards,
> > >>> Torsten.
> > >>>
> > >>> > Am 11.06.2019 um 14:46 schrieb Davide Vaghetti <
> > >>> davide.vaghetti at garr.it>:
> > >>> >
> > >>> > Hi Torsten,
> > >>> >
> > >>> > thanks for further clarifying the use case you have in mind and
> sorry
> > >>> to
> > >>> > come back so late. Let me add some comments.
> > >>> >
> > >>> >> On 04/06/19 19:07, Torsten Lodderstedt 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 unwritten assumption above is that the RP is NOT asking
> explicitly
> > >>> > for the not-yet-existing ephemeral subject type. That's why, as you
> > >>> > write, it'd have to determine what kind of subject type is used in
> the
> > >>> > ID token.
> > >>> >
> > >>> > A simple rule to avoid any confusion could be that the OP MUST NOT
> > >>> > release an ephemeral subject type unless explicitly asked by the
> RP in
> > >>> > the Dynamic Client Registration, as Mike is saying.
> > >>> >
> > >>> > Though, IMHO I think there might be scenarios where you cannot
> always
> > >>> > rely on the awareness of the RP, for example when the original RP
> > >>> passes
> > >>> > the ID token to another RP (which by itself might not be a great
> choice
> > >>> > anyway..).
> > >>> >
> > >>> > What do you guys think?
> > >>> >
> > >>> > Thanks,
> > >>> > Davide
> > >>> >
> > >>> >
> > >>> >>
> > >>> >>>
> > >>> >>> 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
> > >>> >>>
> > >>> >>
> > >>> >
> > >>> > --
> > >>> > 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
> > >>>
> > >>
> > >>
> > >> --
> > >> Nat Sakimura (=nat)
> > >> Chairman, OpenID Foundation
> > >> http://nat.sakimura.org/
> > >> @_nat_en
> > >> _______________________________________________
> > >> Openid-specs-ab mailing list
> > >> Openid-specs-ab at lists.openid.net
> > >> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> > >>
> > > _______________________________________________
> > > Openid-specs-ab mailing list
> > > Openid-specs-ab at lists.openid.net
> > > https://lists.openid.net/mailman/listinfo/openid-specs-ab
> > >
>
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> Nikhef                      Room  H231a
> Science Park 105            Tel.  +31-6-4681 2202
> 1098 XG Amsterdam           Fax   +31-20-592 5155
> The Netherlands             Email msalle at nikhef.nl
>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250410/bc9ee535/attachment-0001.htm>

More information about the Openid-specs-ab mailing list