Self-issued Identifier: Difference between revisions
Jump to navigation
Jump to search
Line 23: | Line 23: | ||
==References== | ==References== | ||
* [https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ Client Bound End-User Assertion] | * [https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ Client Bound End-User Assertion] | ||
* [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] | * [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] of the Decentralized Identifier Foundation. | ||
* [https://tcwiki.azurewebsites.net/index.php?title=Self-issued_Identifier another wiki page on Self-issued ID] | * [https://tcwiki.azurewebsites.net/index.php?title=Self-issued_Identifier another wiki page on Self-issued ID] | ||
* wiki page on [https://tcwiki.azurewebsites.net/index.php?title=Self-issued_OpenID_Provider Self-issued OpenID Provider] | * wiki page on [https://tcwiki.azurewebsites.net/index.php?title=Self-issued_OpenID_Provider Self-issued OpenID Provider] |
Revision as of 19:21, 18 June 2020
Full Title or Meme
This Wiki Page was created to track the use of Self-issued Identifiers in the Open Identity Ecosystem.
Context
- This wiki is focused on the use case of a Self-issued Identifier in a mobile device. It is recognized that other use cases also exist, but it seems that this use case covers all the issues.
- With the rise of the W3C program on Decentralized Identifiers, there is a need for the Identity Ecosystem to coordinate with other teams developing this technology.
- At the 2020-06-16 meeting of the Kantara FIRE WG a liaison effort was approved. That effort is tracked here.
History
- The [OpenID Connect Core 1.0 was issued on 2018-11-08 with section 7 covering self-issued ID. Initial uptake was minimal.
- The Subject ID (SUB) was redefined for that section as "the base64url encoded representation of the thumbprint of the key in the sub_jwk Claim. This 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."
Problems
- The current work of the Decentralized Identifiers has proceed with little concern for how it might integrate with existing Identity Ecosystems.
- Self-issued Identifiers of all types depend on secret values held by the user in portable protected storage, for example a smartphone or WebAuthn key.
- If the user's hardware device is stolen or disable, the recover of the user's identifier can be a challenge which could turn into a UX nightmare if not handled well.
- In particular the SIOP program has been developing standards which look a lot like the DIA and other work in the Kantara work groups without any coordination.
Solutions
- The Subject ID (sub) could be freed from the limitations described above and take its traditional unstructured format. This would allow it to take on any form, like that of a DID.
- The Persistent User ID (puid) could be made mandatory in a new spec that included other information on the need for key recovery, reissue and roll-over. Those processes would be spelled out in some detail.
- Any new identifier format (like the DID) should fit within the definition of this field as would new or propriety methods.
- The id_token could be further described for optional Client Bound End-User Assertion (see reference below) in place of the traditional Bearer Token.
References
- Client Bound End-User Assertion
- Self-Issued OpenID Connect Provider DID Profile of the Decentralized Identifier Foundation.
- another wiki page on Self-issued ID
- wiki page on Self-issued OpenID Provider
- wiki page on Self-Sovereign Identity
- Using OpenID Connect Self-Issued to Achieve DID Auth from Mike Jones
- Who is the special openid connect url issued to and is it a risk? http://self-issued.me