owned this note
owned this note
Published
Linked with GitHub
# 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----------| | | |
| | | | | |
+--------+ +----------+ +--------+
```