OpenID Self Issued Provider

# OpenID Self Issued Provider The Self-Issued OpenID provider (SIOP) chapter of OpenID Connect core sets out a way in which a modified and constrained version of the OpenID Connect protocol can be used for a relying party to contact a special kind of OpenID Connect provider called a SIOP. Consequently because the chapter defines a request that does not conform to a traditional OpenID connect request, it is difficult to reconcile how a self-issued provider could fit into the greater and existing OpenID Connect landscape. This document aims to discuss an alternative approach to SIOP, where instead the capability for an OpenID Provider to issue self-issued responses is treated as an extension of the core OpenID Connect protocol, therefore maintaining backwards compatibility and improving the prospects for the specification to be adopted by existing deployments. In general to-date the concepts that the Self-Issued OpenID provider chapter aims to deal with can be organised into the following: 1. Self Issued Responses 3. Solving the NASCAR problem 4. Request bound client registration 5. Dealing with different OpenID providers deployment architectures Conceptually it's important to distinguish these as seperate issues from the outset as there maybe multiple solutions to each problem. Below is some suggested solutions if we took the above concepts and dealt with them as seperate issues and whilst maintaining compatibility with OpenID Connect Core. # Self Issued Responses ## Requesting a self signed response A client making an OpenID connect request can advertise its support for "self issued responses" through supplying the additional request information. siop_uris A space seperated string denoting the URI types that the OpenID provider supports. The following is a non-normative example of an OpenID Connect request whereby the client is expressing support for self issued responses ``` HTTP/1.1 302 Found Location: https://wallet.example.com/authorize? response_type=id_token &scope=openid%20profile &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &siop_uris=did%3Aion%3A%20did%3Aelem%3A%20 ``` ## OpenID Provider Discovery An OpenID Provider who wishes to advertise their support for self issued responses can include the following metadata in their OpenID Connect Metadata siop_supported Boolean value indicating that the OpenID provider supports self-issued responses siop_uris_supported A JSON array of strings representing the URI types that the OpenID provider supports. The following is a non-normative example of the relevant entries in the openid-configuration meta data for an OpenID Provider supporting self issued responses ``` { "siop_supported": true, "siop_uris_support": [ "did:ion:", "did:elem:", "did:sov:" ] } ``` ## Self Issued Response Ideas/Questions - sub claim has to be a valid uri in a SIOP response - Default behaviour is sub_jwk as per current spec where the thumbprint is formated into a URN e.g `urn:jwk_thum:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs` - An extension point exists where other subject identifier URI types can be used e.g decentralized identifiers - We could look to embedded an authentication assertion that is from OP into the SIOP response so that the current OpenID provider security model holds up? - What do we want to do with the `iss` field, currently it is used for relying parties to detect the id_token is a self issued one and hence apply the required validation rules, however using `https://self-issued.me` is problematic because of the statically hosted openid metadata. ``` { "sub": "urn:jwk_thum:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs", "provider_assertion": "rtwr.wrtw.wrtbr" <= ES "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" } } ``` Response with DID ``` { <- Signed by the provided "iss": "https://provider.example.com", "sub": "did:example:1234", "sub_assertion": "<jwt>", <- Signed by did:example:1234 "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` # Solving the NASCAR problem > Using something like a native browser feature or a custom URL scheme to prevent the need for the relying party to feature all of their supported login providers on their login screen. # Request bound client registration > When dynamic client registration is not an option usually because of the OpenID providers deployment architecture # Dealing with different OpenID providers deployment architectures > Related to above when the OpenID Provider is not a http(s) accessible web server and instead is invoked via a universal link or is a locally running SPA # OpenID Provider Attestation Because the signing mechanism in SIOP is asserting control over the subject identifier rather than the provider attesting to the occurance of an authentication event, there must be an alternative way to express this. WebAuthn has a similar concept known as Authenticator Attestation, which allows a relying party to know properties about the authenticator that was used e.g the vendor of the authenticator. SIOP is attempting to do something similar, where from a vendor perspective there might be a single provider, but many distributed instances of that provider running as mobile apps, PWA's or as a browser extension. // `id_token` -> signed by the provider Example SIOP response Payload ``` { "iss": "https://provider.example.com", "sub": "did:example:1234", "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` # Self Issued Responses supported via an extension to `subject_types` Torsten suggested, maybe instead `identity_types`? As per [chapter 8](https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes) two types of subject identifiers are supported, what if we used this as the basis for a SIOP response? OpenID providers could advertise support for basic self issued subject identifiers via a new subject_type of `jwkthumb` JWK Thumbprint Subject Identifier Type. When this subject identifier type is used, the `sub` value MUST be a JSON Web Key fingerprint (as per spec...) of an asymmetric key pair. When this subject identifier type is used in an `id_token` it MUST be accompanied with a `sub_asrt` claim, where the value equals a JWT signed by the key pair represented by the fingerprint in the `sub` value. `did` Decentralized Identifier Type. When this subject identifier type is used the `sub` value MUST be a Decentralized Identifier. When this subject identifier type is used in an `id_token` it MUST be accompanied with a `sub_asrt` claim, where the value equals a JWT signed by a key pair that is associated to the Decentralized Identifier present in the `sub` field. Example request where a client is expressing support for these subject types ``` HTTP/1.1 302 Found Location: https://provider.example.com/authorize? response_type=id_token &scope=openid%20profile &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &subject_types=jwkthumb%20did%3Aion%3A%20did%3Aelem%3A%20 ``` Ordinary OpenID Provider ``` signed by provider.example.com { "iss": "https://provider.example.com", + "sub": "123456789", "aud": "https://www.faber.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` ``` signed by provider.example.com { "iss": "https://provider.example2.com", + "sub": "123456789", "aud": "https://www.faber.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` Example 1 `sub` as did ``` signed by provider.example.com { "iss": "https://provider.example.com", "sub": "did:example:1234", "sub_asrt": "<jwt-signed-by-key-material-associated-to-sub>", "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` Example 2 using the subject identifiers draft ``` signed by provider.example.com { "iss": "https://provider.example.com", "sub": "123456789", "sub_id": { "subject_type": "did", "phone_number": "did:example:1234", "sub_asrt": "<jwt-signed-by-key-material-associated-to-sub>" }, "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 } ``` Example of a provider expressing support in their OpenID Connect Metadata endpoint ``` { "subject_types_supported": [ "public", "pairwise", "jwkthumb", "did:ion:", "did:key:" ] } ``` Outstanding question, what does the provider sign with when it is a PWA? Some form of delegated assertion like how FIDO does group attestations or more exotic crypto like ECDAA. # Notes about IDP vs IDSP The term identity provider today is used to describe a service (or a group of services) that are providing an end-user with an identity within a domain, protocols like OpenID Connect then also allow for this domain bound identity to be relied upon outside of the domain which is often refered to as federated identity. The problem with this architecture and terminology is that the identity becomes entirely bound to the service providing it (the IDP). Instead ideally, identities or more over the identifiers that an identity is oftened centered around should be portable, in otherwords end-users should be afforded the ability to change the service provider for an identity without repercussion. To do this, there needs to some mechanism underwhich ownership over an identifier can be established that does not require a tight coupling to the provider and asymmetric cryptography alone enables such a phenomena. .... Having the ability to `import` an identity into a provider fundamentally makes us questions the language of IDP because the provider is no longer asserting an end-users identity within a domain but merely providing services to enable the end-user to use that identity with whichever relying party it so chooses. Hence the terminology of Identity Service Provider (IDSP). # Naming ideas - Self Issued OpenID Provider is like BYOID (Bring your own ID) - Portable Identifiers # Claims provider integration This ASCI art is a W.I.P ``` +--------+ +----------+ +--------+ | |------(1) OpenID Request---------->| | | | | | | |----------------(1) OpenID Request--------------------->| | | | | | | | | | | | +--------+ | | | | | | | | | | | | | | | End- | | | | Client | | OP |<--(2) AuthN & AuthZ-->| User |<--(2) AuthN & AuthZ-->| Claim | |(Relying| | (SIOP) | | | |Provider| | Party) | | | *--------* | (OP) | | | | | | | | | | |<--------------(3) OpenID Response----------------------| | | |<-----(3) OpenID Response----------| | | | | | | | | | +--------+ +----------+ +--------+ ```

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.