[Openid-specs-ab] Spec Call Notes 9-May-19
Nat Sakimura
sakimura at gmail.com
Mon Apr 7 21:46:37 UTC 2025
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250408/200f5460/attachment-0001.htm>
-------------- next part --------------
%%%
title = "OpenID Connect Ephermeral Subject Identifier Draft 01"
abbrev = "oidc-esid"
ipr = "none"
workgroup = "Connect"
keyword = ["openid", "ephemeral", "subject", "privacy"]
[seriesInfo]
name = "OpenID-Draft"
value = "openid-connect-ephemeral-subject-identifier-1.0_01"
status = "standard"
[pi]
subcompact = "yes"
private = "Draft-01"
tocdepth = "5"
iprnotified = "no"
[[author]]
initials="N."
surname="Sakimura"
fullname="Nat Sakimura"
organization="NAT.Consulting"
[author.address]
email = "nat at nat.consulting"
[[author]]
initials="E."
surname="Jay"
fullname="Edmund Jay"
organization="Illumila"
[author.address]
email = "ejay at mgi1.com"
%%%
.# Abstract
OpenID Connect specifies the public and pairwise subject identifier types. These types of subject identifiers allow relying parties to keep track of the End-User across multiple visits to the relying party application by correlating the subject identifier. This document specifies an ephemeral subject identifier type that prevents correlation of the subject identifier across multiple visits to enhance user privacy.
.# Warning
This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
.# Foreword
The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participants). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established has the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.
{mainmatter}
# Introduction
This document specifies an ephemeral subject identifier type for [OpenID Connect Core 1.0][OIDC]. The ephemeral subject identifier identifies the End-User for a short time and remains constant for the duration of the authentication session. In subsequent visits by the End-User to a Relying Party application that requires authentication, the authorization server will return a subject identifier with a different value. The authorization server provides an ephemeral subject identifier to the Relying Party in the ID Token and UserInfo endpoint response as specified by [OpenID Connect Core 1.0][OIDC].
# Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In the .txt version of this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this document, values to be taken literally are indicated by the use of this fixed-width font.
# Terms and definitions
For the purpose of this document, the terms defined in [RFC6749], and [OpenID Connect Core 1.0][OIDC] apply.
# Ephemeral Identifier
This document adds a new subject identifier type as follows, in addition to what is defined in Section 8 of [OpenID Connect Core 1.0][OIDC]:
ephemeral
: This provides a different *sub* value to each visit by the End User to a relying party, so as not to enable Clients to correlate the End-User's multiple visits.
# OpenID Provider Discovery Metadata
The OpenID Provider indicates support for ephemeral subject identifiers in the metadata document.
This document defines the following new value for the _subject\_types\_supported_ metadata of [OpenID Discovery 1.0][OpenID.Discovery]:
* _ephemeral_ - ephemeral subject identifiers
# Client Registration
The RP requests the OP to return ephemeral subject identifiers by registering _ephemeral_ as the _subject\_type_ in [OpenID Dynamic Registration 1.0][OpenID.Registration] or by other means.
# Security Considerations
The generated ephemeral identifier needs to be unique over time.
Otherwise, the RP may link two different users to the same record and will cause a security incident.
One way to achieve uniqueness is to use the hash of the combination of a cryptographic
random and the timestamp as the *sub* value.
# Privacy Considerations
The privacy objectives of this document are as follows:
1. to make it unfeasible for the RP to link two independent visits by the user. Inclusion of cryptographic random in the input to the hash function that generates the subject identifier would achieve it.
2. to make it unfeasible for colluding RPs to link two independent visits among them.
# References
## Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.
[BCP14] - Key words for use in RFCs to Indicate Requirement Levels
[BCP14]: https://tools.ietf.org/html/bcp14
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels
[RFC2119]: https://tools.ietf.org/html/rfc2119
[RFC8174] - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
[RFC8174]: https://tools.ietf.org/html/rfc8174
[RFC6749] - The OAuth 2.0 Authorization Framework
[RFC6749]: https://tools.ietf.org/html/rfc6749
[OIDC] - OpenID Connect Core 1.0 incorporating errata set 1
[OIDC]: https://openid.net/specs/openid-connect-core-1_0.html
[OpenID.Discovery] - OpenID Connect Discovery 1.0
[OpenID.Discovery]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OpenID.Registration] - OpenID Connect Registration 1.0
[OpenID.Registration]: http://openid.net/specs/openid-connect-registration-1_0.html
{backmatter}
# Copyright notice & license
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250408/200f5460/attachment-0001.html>
More information about the Openid-specs-ab
mailing list