[Openid-specs-ab] Contributing a Self-Issued OpenID Provider v2 draft
Tom Jones
thomasclinganjones at gmail.com
Tue Nov 24 00:26:12 UTC 2020
in my opinion this does not solve the fundamental problem of SIOP which is
communication between the browser and the siop (wallet). I don't see much
point in standards that will have a similar acceptance to OpenID 2.0 with
incomprehensible identifiers and disjointed UX.
Peace ..tom
On Wed, Nov 18, 2020 at 5:06 PM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Dear AB/Connect WG experts,
>
>
> I would like to contribute a Self-Issued OpenID Provider v2 draft to the
> working group. Several working group members including Torsten, Tobias, Mike
> and Pam helped review it, and it incorporates ideas from Tom's OpenID
> Self Issued Identifiers draft.
>
> It is a work in progress, but I think the document is ready for others to
> review and for working group discussion.
>
>
>
> Please find below is the full text of the draft. You can also read the
> current version of the draft at the following link:
> https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view
>
>
> Best,
>
> Kristina
>
>
>
> Self-Issued OpenID Provider v2 draft
>
> This document defines a new scope as well as rules for the use of OpenID
> Connect to present credentials that may be validated through the use of
> decentralized identifiers, and Verifiable Credentials using a Self-Issued
> OpenID Provider (section 7 of [OpenID.Core]) in addition to the current
> scope.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#7-Self-Issued-OpenID-Provider>7.
> Self-Issued OpenID Provider
>
> OpenID Connect supports Self-Issued OpenID Providers (Self-Issued OPs) -
> personal OpenID Providers that issue self-signed ID Tokens, enabling
> portability of the identities among providers.
>
> This section defines how a Holder provides ID Token to the Relying
> Party(RP) through the Self-Issued OP, and how a Holder asks and receives
> attested claims that can be included in the ID Token.
>
> Specifications for the few additional parameters used and for the values
> of some parameters in the Self-Issued case are defined in this section.
>
> NOTE: this section only outlines the verification process for the RP to
> request authentication information (either only log-in and/or claims) from
> Self-Issued OP. Issuance of the credentials from the OpenID Provider to
> Self-Issued OP that is acting in RPs capacity is out of scope of this
> section.
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#71-Terminology>7.1.
> Terminology
>
> Common terms in this document come from four primary sources:
> [DID-CORE],[VC-DATA], [RFC6749] and [OpenID.Core]. In the case where a term
> has a definition that differs, the definition below is authoritative.
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#72-Protocol-Flow>7.2.
> Protocol Flow
>
> Self-Issued OpenID Provider Request is an OpenID Connect Authentication
> Request that results in a Holder providing ID Token to the Relying Party
> through the Self-Issued OP. ID Token MAY include attested claims about the
> Holder.
>
> +----------+ +--------+
> | | | |
> | |-------(1) Self-Issued OpenID Provider Request----->| |
> | | (OpenID Connect Authentication Request) | |
> | | +--------+ | |
> | | | | | |
> | | | Hol- | | |
> | RP | | der |<-(2) AuthN & AuthZ->| OP |
> | | | | | (Self- |
> | | +--------+ | Issued |
> | | | OP) |
> | |<------(3) Self-Issued OpenID Provider Response-----| |
> | | (ID Token) | |
> | | | |
> +----------+ +--------+
>
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#73-Self-Issued-OpenID-Provider-Discovery>7.3.
> Self-Issued OpenID Provider Discovery
>
> Self-Issued OP MUST associate a custom schema openid:// with itself.
> Relying Party MUST call openid:// when sending a request to a Self-Issued
> OP.
>
> NOTE: consider using deeplinks for discovery in the scenarios when
> Self-Issued OP is PWA
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#74-Self-Issued-OP-Registration>7.4.
> Self-Issued OP Registration
>
> OpenID Connect defines the following registration parameters to enable
> Relying Party to provide information about itself to a Self-Issued OP that
> would normally be provided to an OP during Dynamic RP Registration:
>
> -
>
> registration
> OPTIONAL. This parameter enables RP Registration Metadata to be passed
> in a single, self-contained parameter. The value is a JSON object
> containing RP Registration Metadata values.
> NOTE: Do we also need to support JWT registration values?
> -
>
> registration_uri
> OPTIONAL. This parameter enables RP Registration Metadata to be passed
> by reference, rather than by value. The request_uri value is a URL using
> the https scheme referencing a resource containing RP Registration Metadata
> values.
>
> RP Registration Metadata values are defined in Section 7.4.3 and Section
> 2.1 of the OpenID Connect Dynamic RP Registration 1.0 [OpenID.Registration]
> specification.
>
> If Self-Issued OP supports the same parameters, Self-Issued OpenID
> Provider flow continues, if Self-Issued OP does not support, it returns an
> error.
>
> Configuration values should preferably sent by reference as a URI using
> registration_uri parameter, but when RP cannot host a webserver,
> configuration values should be sent by value using registration parameter.
>
> RP MUST use either of there parameters, but if one of these parameters is
> used, the other MUST NOT be used in the same request.
>
> These registration parameters SHOULD NOT be used when the OP is not a
> Self-Issued OP.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#741-Passing-Relying-Party-Registration-Metadata-by-Value>7.4.1.
> Passing Relying Party Registration Metadata by Value
>
> The registration SIOP Request parameter enables RP Registration Metadata
> to be passed in a single, self-contained parameter.
>
> The registration parameter value is represented in an OAuth 2.0 request as
> a UTF-8 encoded JSON object (which ends up being form-urlencoded when
> passed as an OAuth parameter). When used in a Request Object value, per
> Section 6.1, the JSON object is used as the value of the registration
> member.
>
> Following value MUST be included in the registration parameter when it is
> used:
>
> - client_id
> - redirect_uri value of the RP.
> NOTE: Is this still needed?
>
> The Registration parameters that would typically be used in requests to
> Self-Issued OPs are policy_uri, tos_uri, and logo_uri. If the RP uses more
> than one Redirection URI, the redirect_uris parameter would be used to
> register them. Finally, if the RP is requesting encrypted responses, it
> would typically use the jwks_uri, id_token_encrypted_response_alg and
> id_token_encrypted_response_enc parameters.
>
> Registration parameter may include decentralized identifier of the RP.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#742-Passing-Relying-Party-Registration-Metadata-by-Reference>7.4.2.
> Passing Relying Party Registration Metadata by Reference
>
> The registration_uri SIOP Request parameter enables RP Registration
> Metadata to be passed by reference.
>
> This parameter is used identically to the request parameter, other than
> that the Relying Party registration metadata value is retrieved from the
> resource at the specified URL, rather than passed by value.
>
> The contents of the resource referenced by the URL MUST be a RP
> Registration Metadata Object. The scheme used in the registration_uri value
> MUST be https. The request_uri value MUST be reachable by the Self-Issued
> OP, and SHOULD be reachable by the RP.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#743-Relying-Party-Registration-Metadata-Values>7.4.3.
> Relying Party Registration Metadata Values
>
> OpenID Conect defineds following RP Registration Metadata values that are
> used by RP to provide information about itself to the Self-Issued OP:
>
> Static Values
>
> - authorization_endpoint
> REQUIRED. MUST be openid:.
> - issuer
> REQUIRED. MUST be https://self-issued.me/v2
> - response_types_supported
> MUST be id_token
>
> Dynamic Values
>
> - scopes_supported
> REQUIRED. Valid values include openid, profile, email, address, and
> phone.
> - subject_types_supported
> REQUIRED. Valid values include pairwise and public.
> - sub_types_supported
> REQUIRED. Valid values include jkt and concrete did methods supported.
> did methods supported must take the value of Method Name in Chapter 9
> of did-spec-registries
> <https://w3c.github.io/did-spec-registries/#did-methods>, such as
> did:peer:
> - id_token_signing_alg_values_supported
> REQUIRED. Valid values include RS256, ES256, ES256K, and EdDSA.
> - request_object_signing_alg_values_supported
> REQUIRED. Valid values include none, RS256, ES256, ES256K, and EdDSA
>
> The following is a non-normative example of RP Registration Metadata
> Values supported by Self-Issued OP:
>
> {
> "authorization_endpoint":
> "openid:",
> "issuer":
> "https://self-issued.me/v2",
> "scopes_supported":
> ["openid", "profile", "email", "address", "phone"],
> "response_types_supported":
> ["id_token"]
> "subject_types_supported":
> ["pairwise"],
> "sub_types_supported":
> ["did:peer:", "did:ion:"],
> "id_token_signing_alg_values_supported":
> ["ES256", "ES256K"],
> "request_object_signing_alg_values_supported":
> ["ES256", "ES256K"]
> }
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#7431-Sub-Types>7.4.3.1.
> Sub Types
>
> A sub type is used by Self-Issued OP to advertise which types of
> identifiers are supported for the sub claim. Two types are defined by
> this specification:
>
> jkt
> JWK Thumbprint Subject sub type. When this subject sub type is used, the
> sub Claim value MUST be the base64url encoded representation of the
> thumbprint of the key in the sub_jwk Claim. [RFC7638]
>
> did
> Decentralized sub type. This sub type MUST specify concrete Decentralized
> Identifier (DID) methods supported using the value of Method Name in
> Chapter 9 of did-spec-registries
> <https://w3c.github.io/did-spec-registries/#did-methods>, such as
> did:peer:. When this sub type is used, the sub value MUST be a DID
> defined in [DID-CORE].
>
> NOTE: Consider adding a subject type for OpenID Connect Federation entity
> statements.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#744-Relying-Party-Registration-Metadata-Error-Response>7.4.4.
> Relying Party Registration Metadata Error Response
>
> OpenID Connect defines the following error codes that MUST be returned
> when Self-Issued OP does not support all of the Relying Party Registration
> metadata values received from the Relying Party in the registration
> parameter:
>
> - value_not_supported
> The Self-Issued OP does not support more than one of the RP
> Registration Metadata values defined in Section 7.4.3.
> - invalid_registration_uri
> The registration_uri in the Self-Issued OpenID Provider request
> returns an error or contains invalid data.
> - invalid_registration_object
> The registration parameter contains an invalid RP Registration
> Metadata Object.
>
> Error response must be made in the same manner as defined in Section
> 3.1.2.6.
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#75-Self-Issued-OpenID-Provider-Request>7.5.
> Self-Issued OpenID Provider Request
>
> The RP sends the Authentication Request to the Authorization Endpoint with
> the following parameters:
>
> - scope
> REQUIRED. scope parameter value, as specified in Section 3.1.2.
> - response_type
> REQUIRED. Constant string value id_token.
> - client_id
> REQUIRED. RP ID value for the RP, which in this case contains the
> redirect_uri value of the RP.
> - sub_type
> REQUIRED. A space seperated string denoting the URI types that the
> OpenID provider supports.
> - id_token_hint
> OPTIONAL. id_token_hint parameter value, as specified in Section
> 3.1.2. If the ID Token is encrypted to the Self-Issued OP, the sub
> (subject) of the signed ID Token MUST be sent as the kid (Key ID) of the
> JWE.
> - claims
> OPTIONAL. claims parameter value, as specified in Section 5.5.
> - registration
> OPTIONAL. This parameter is used by the RP to provide information
> about itself to a Self-Issued OP that would normally be provided to an OP
> during Dynamic RP Registration, as specified in Section 7.2.1.
> - request
> OPTIONAL. Request Object value, as specified in Section 6.1. The
> Request Object MAY be encrypted to the Self-Issued OP by the RP. In this
> case, the sub (subject) of a previously issued ID Token for this RP MUST be
> sent as the kid (Key ID) of the JWE.
>
> Other parameters MAY be sent. Note that all Claims are returned in the ID
> Token.
>
> The entire URL MUST NOT exceed 2048 ASCII characters.
>
> The following is a non-normative example HTTP 302 redirect response by the
> RP, which triggers the User Agent to make an Authentication Request to the
> Self-Issued OP (with line wraps within values for display purposes only):
>
> HTTP/1.1 302 Found
> Location: openid://?
> response_type=id_token
> &client_id=https%3A%2F%2Fclient.example.org%2Fcb
> &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
> &scope=openid%20profile
> &identifier_uri=jwkthumb%3A%20did%3Akey%3A%20
> &state=af0ifjsldkj
> &nonce=n-0S6_WzA2Mj
> ®istration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
> client.example.org%2Flogo.png%22%7D
>
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#76-Self-Issued-OpenID-Provider-Response>7.6.
> Self-Issued OpenID Provider Response
>
> Self-Issued OpenID Provider Response is returned when Self-Issued OP
> supports all of the Relying Party Registration metadata values received
> from the Relying Party in the registration parameter. If even one of the
> Relying Party Registration Metadata Values is not supported, Self-Issued OP
> MUST return an error according to Section 7.4.4.
>
> OpenID Connect defines the following claims to be included in the ID token
> for use in Self-Issued OpenID Provider Responses:
>
> - sub
> - REQUIRED. Subject identifier value, represented by a URI. When
> sub type is jkt, the value is the base64url encoded representation
> of the thumbprint of the key in the sub_jwk Claim. When sub type is
> did, the value is a decentralized identifier. The thumbprint value
> is computed as the SHA-256 hash of the octets of the UTF-8 representation
> of a JWK constructed containing only the REQUIRED members to represent the
> key, with the member names sorted into lexicographic order, and with no
> white space or line breaks. For instance, when the kty value is RSA, the
> member names e, kty, and n are the ones present in the constructed JWK used
> in the thumbprint computation and appear in that order; when the kty value
> is EC, the member names crv, kty, x, and y are present in that order. Note
> that this thumbprint calculation is the same as that defined in the JWK
> Thumbprint [RFC7638] specification.
> - sub_jwk
> - REQUIRED. a secure binding between the subject of the verifiable
> credential and the subject identifier (and related keys) of the holder who
> creates the presentation. When subr type is jkt, the key is a bare
> key in JWK [JWK] format (not an X.509 certificate value). When sub type is
> did, sub_jwk MUST contain a kid that is a DID URL referring to the
> verification method in the Self-Issued OP’s DID Document that can be used
> to verify the JWS of the id_token directly or indirectly. The sub_jwk value
> is a JSON object. Use of the sub_jwk Claim is NOT RECOMMENDED when
> the OP is not Self-Issued.
> - vp
> - OPTIONAL. A JSON object, that represents a JWT verifiable
> presentation, following W3C Verifiable Credentials Specification
> [VC-DATA-MODEL]. Verifiable Credentials must be embedded in the Verifiable
> Presentation following W3C Verifiable Credentials Specification
> [VC-DATA-MODEL]
>
> Verifiable Presentation is data derived from one or more Verifiable
> Credentials, issued by one or more issuers, that is shared with a specific
> verifier. Verifiable Credential is a set of one or more claims made by an
> issuer.
>
> Self-Issued OP may present credentials to the RP using Verifiable
> Presentation credential format by including it in the vp claim inside the
> ID token.
>
> Whether the Self-Issued OP is a mobile client or a web client, response is
> the same as the normal Implicit Flow response with the following
> refinements. Since it is an Implicit Flow response, the response parameters
> will be returned in the URL fragment component, unless a different Response
> Mode was specified.
>
> 1. The iss (issuer) Claim Value is `https://self-issued.me/``
> <https://self-issued.me/>.
> 2. A sub_jwk Claim is present, with its value being the public key
> used to check the signature of the ID Token.
> 3. The sub (subject) Claim value is either the base64url encoded
> representation of the thumbprint of the key in the sub_jwk Claim or a
> decentralized identifier.
> 4. No Access Token is returned for accessing a UserInfo Endpoint, so
> all Claims returned MUST be in the ID Token.
>
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#77-Self-Issued-ID-Token-Validation>7.7.
> Self-Issued ID Token Validation
>
> To validate the ID Token received, the RP MUST do the following:
>
> 1. The Relying Party (RP) MUST validate that the value of the iss (issuer)
> Claim is https://self-isued.me. If iss contains a different value, the
> ID Token is not Self-Issued, and instead it MUST be validated according to
> Section 3.1.3.7.
> 2. The RP MUST validate that the aud (audience) Claim contains the
> value of the redirect_uri that the RP sent in the Authentication
> Request as an audience.
> 3. The RP MUST validate the signature of the ID Token. When sub type is
> jkt, validation is done according to JWS [JWS] using the algorithm
> specified in the alg Header Parameter of the JOSE Header, using the key in
> the sub_jwk Claim. When sub type isdid, vvalidation is done using the
> key derived as a result of DID Resolution as defined in [DID-CORE]. The key
> is a bare key in JWK format (not an X.509 certificate value) when sub type
> isjkt or may be another key format when sub type is did.
> 4. Default alg value is RS256. It MAY also be ES256, ES256K or EdDSA.
> 5. The RP MUST validate that thesub claim is bound to the sub_jwk value.
> When sub type isjkt, the RP MUST validate that the sub Claim value is
> the base64url encoded representation of the thumbprint of the key in the
> sub_jwk Claim, as specified in Section 7.6. When sub type is did, the
> RP MUST validate that the kid of the sub_jwk claim matches the
> verification method from the DID Document that is obtained by resolving
> decentralized identifier included in sub claim.
> 6. The current time MUST be before the time represented by the exp Claim
> (possibly allowing for some small leeway to account for clock skew).
> 7. The iat Claim can be used to reject tokens that were issued too far
> away from the current time, limiting the amount of time that nonces need to
> be stored to prevent attacks. The acceptable range is RP specific.
> 8. If a nonce value was sent in the Authentication Request, a nonce Claim
> MUST be present and its value checked to verify that it is the same value
> as the one that was sent in the Authentication Request. The RP SHOULD check
> the nonce value for replay attacks. The precise method for detecting
> replay attacks is RP specific.
>
> The following is a non-normative example of a base64url decoded
> Self-Issued ID Token (with line wraps within values for display purposes
> only):
>
> {
> "iss": "https://self-issued.me",
> "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
> "aud": "https://client.example.org/cb",
> "nonce": "n-0S6_WzA2Mj",
> "exp": 1311281970,
> "iat": 1311280970,
> "sub_jwk": {
> "kty":"RSA",
> "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
> 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
> tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
> QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
> SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
> w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
> "e":"AQAB"
> },
> "vp": {
> "@context": [
> "https://www.w3.org/2018/credentials/v1",
> "https://www.w3.org/2018/credentials/examples/v1"
> ],
> "type": ["VerifiablePresentation"],
> "verifiableCredential": ["..."]
> }
> }
>
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#Possible-Future-Work>Possible
> Future Work
>
> - Define Claims Issuance Flow
> - Need to defined a flow how Self-Issued OP requests and receives
> claims from a Claims Provider that Self-Issued OP can present to the RP in
> Self-Issued OpenID Provider response.
> - Define a flow when RP and Self-Issued OP are on the same device
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#References>References
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#Normative-References>Normative
> References
>
> - [DID-CORE] https://github.com/w3c/did-core (not yet a ratified draft)
> - [VC-DATA] https://www.w3.org/TR/vc-data-model/
> - [RFC6749] https://tools.ietf.org/html/rfc6749
> - [RFC6750] https://tools.ietf.org/html/rfc6750
> - [OpenID.Core] https://openid.net/specs/openid-connect-core-1_0.html
> - [RFC7638] https://tools.ietf.org/html/rfc7638
> - [OpenID.Registration]
> https://openid.net/specs/openid-connect-registration-1_0.html
> - [did-spec-registries]
> https://w3c.github.io/did-spec-registries/#did-methods
>
> <https://hackmd.io/NlVqlsfmQf6jeWqIlq8i7g?view#Non-Normative-References>Non-Normative
> References
>
> - [draft-jones-self_issued_identifier]
> https://bitbucket.org/openid/connect/src/master/SIOP/draft-jones-self_issued_identifier.md
> - [siop-requirements]
> https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md
>
>
>
> _______________________________________________
> 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/20201123/08f372bd/attachment.html>
More information about the Openid-specs-ab
mailing list