In order for an OpenID Connect Relying Party (RP) to utilize OpenID Connect services for an End-User, the RP needs to know where the OpenID Provider is. RPs can use OpenID Connect Discovery.
Specifically, the extension provides an alternative method for OpenID Connect Issuer Discovery, Section 2. With Unstoppable Login, clients will resolve WebFinger information using records stored on a domain name instead of resolving WebFinger information from a server. Essentially, this process allows End-Users to specify their OpenID Provider using their domains.
Unstoppable Webfinger uses a variety of records stored on domains to resolve a WebFinger Issuer discovery request. For Unstoppable Login, webfinger information can be stored on the domain in the following ways: by request, reference, or value.
WebFinger requires the following information to make a discovery request:
- resource: Identifier for the target End-User that is the subject of the discovery request
- host: Server where a WebFinger service is hosted
- rel: URI that identifies the type of service whose location is being requested
Traditional Issuer discovery requires only the requestor resource and host to form the request, the rel must be http://openid.net/specs/connect/1.0/issuer to make an issuer request.
{
“webfinger”: {
“alice”: { “https://example.com/webfinger/rel”: “{\“uri\”:\“ipfs://Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu\”}”
“bob”: {“https://example.com/webfinger/rel”: “{\“host\”:\“example.com\”}”},
“charlie”: {“https://example.com/webfinger/rel”: “{\“value\”:\“{...Webfinger JRD Doc...}\”}”}
}| Name | Type | Value |
|---|---|---|
| webfinger | TXT | BASE64 encoded Document from above example |
This is a method used to construct a WebFinger request. The below fields are used to construct a WebFinger request, that a Client can then resolve.
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. If one was resolving this information on domain.tld, the webfinger resource constructed would be acct:user@domain.tld. If no user is present in the record, the account would be domain itself, i.e. acct:@domain.tld. |
| host | Server where a WebFinger service is hosted. |
| rel | The OPTIONAL URI that identifies the type of service whose location is being requested, defaults to http://openid.net/specs/connect/1.0/issuer, used for Unstoppable Issuer Discovery. |
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. This is interpreted in the same way as it is in the “By Request” flow. |
| uri | A URI specifying the location of a WebFinger JRD Document. This can be a https scheme URL, or a DID, or even a decentralized storage URL. |
| rel | The OPTIONAL URI that identifies the type of service whose location is being requested. This is interpreted in the same way as it is in the “By Request” flow. |
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. This is interpreted in the same way as it is in the “By Request” flow. |
| value | The WebFinger JRD Document in plaintext. |
| rel | The OPTIONAL URI that identifies the type of service whose location is being requested. This is interpreted in the same way as it is in the “By Request” flow. |
Unstoppable Authentication is a group of methods for authenticating End-Users of blockchain based domain names. OpenID Connect has no standards around authentication, other than metadata encoded inside jwts, e.g. amr, Authentication Method Reference Values.
Unstoppable Authentication uses two types of authentication that authorization servers will need to support Logins with Unstoppable: owner-based authentication and record-based authentication.
This is the default authentication method used for Unstoppable Authentication. To consent, users sign a message provided by an Authentication server, instead of using a username and password combination. We use the owner of the domain as the public key that is recovered.
The Authentication server should use the AMR Value of uns-own.
For domains owned by multisig wallets, owner-based authentication isn’t sufficient for authentication because there is no private key associated with the owner account. To solve this problem, domains can specify a private key as a record on the domain.
The below fields are used to specify a public key that can be used for authentication.
It’s recommended that DApps support the web3 and oob methods at a minimum.
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. If one was resolving this information on domain.tld, the webfinger resource constructed would be acct:user@domain.tld. If no user is present in the record, the account would be domain itself, i.e. acct:@domain.tld. |
| addr | An Ethereum address corresponding to a private key a user owns. |
| addr_type_hint | An OPTIONAL hint for the Authentication server to suggest sign-in methods. If no hint is present the Authentication server should display as many methods as it can support. |
For context, addr_type_hint can have the following values:
| Value | Description |
|---|---|
| web3 | Signing done via Injected web3 instance |
| trezor | Signing done via Trezor Wallet. This method is considered uns-hwk. |
| ledger | Signing done via Ledger Wallet. This method is considered uns-hwk. |
| walletconnect | Signing done via Wallet Connect Modal |
| walletlink | Signing done via Wallet Link Modal |
| mewconnect | Signing done via My Ether Wallet Connect, used by their Mobile app |
| formatic | Signing done via Formatic Wallet |
| portis | Signing done via Portis Wallet |
| oob | Signing done via Out of Band signing. Authorization server should have a message to sign displayed and have a form for the user to paste the signature for authentication. |
If the Ethereum account is stored using a hardware wallet, the AMR Value SHOULD be uns-hwk. For all other address types, the Authentication server should use the AMR Value of uns-swk.
The Authentication Server should use the AMR Value of uns-swk.
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. This is interpreted in the same way as it is in the “Ethereum Address” flow. |
| jwks | A JWKS document stored in plaintext containing the signing key(s) used to prove the identity of the End-User |
Those records would correspond to the user alice@domain.tld.
{
“authentication”: {
“alice”: “{\“addr\”:\“0x1234567890123456789012345678901234567890\”,\“addr_type_hint\”:\“web3\”}”,
“bob”: “{\“jwks\”:\“{\“keys\”:[...]}\”}”,
“charlie”: “{\“jwks_uri\”:\“ipfs://Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu\”}”
}
}The Authentication Server should use the AMR Value of uns-swk.
| Field | Description |
|---|---|
| user | The OPTIONAL user of the account. This is interpreted in the same way as it is in the "Ethereum Address" flow. |
| jwk_uri | URL of the JWKS document containing the signing key(s) used to prove the identity of the End-User |
Access tokens are put into an authorization header using the “Bearer” authentication scheme with the following format:
Authentication: "Bearer " + Base64<username + ":" + token_id>
username = The subject of the access_token
token_id = The token returned from the token_endpoint earlierThis scheme is very similar to the Basic Authentication scheme, but for compatibility purposes, the token is opaque and therefore a Bearer token.
The Authorization server supports several standards beyond Authentication and Authorization explained in these docs.
- JWT Token Introspection/Userinfo **
- JRAM Responses+
- Client Registration & Management
- Request Objects
- Resource Indicators
- Token Revocation
- private_key_jwt Client Authentication
- PKCE
- Rotating Refresh Tokens
- Encrypted JWT Responses
- Backchannel Logout+
+The OIDC Consortium hasn’t formally audited these features offered by the server.