[Openid-specs-ab] Ephemeral Identifier
Mischa Salle
msalle at nikhef.nl
Thu Apr 10 16:51:49 UTC 2025
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&
> >>> >>>>>>> ;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&
> >>> >>>>>>>
> >>> ;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
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
More information about the Openid-specs-ab
mailing list