Difference between revisions of "Self-issued Identifier"

From MgmtWiki
Jump to: navigation, search
(→‎Problems)
 
(35 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
When the [[Subject]] of an interchange is given the ability to create an manager their own [[Identifier]] and their own [[Identifier or Attribute Provider]].
+
When the [[Subject]] of an interchange is given the ability to create and manage their own [[Identifier]] and their own [[Identifier or Attribute Provider]] in support of those [[Identifier]]s and [[Attribute]]s.
  
 
==Context==
 
==Context==
−
* As a part of the effort to create [[OpenID Connect]] the option for the [[Subject]] to issue their own [[Identifier]]s was explicitly enabled.
+
* As a part of the effort to create [[OpenID Connect]] the option for the [[Subject]] to issue their own [[Identifier]]s was explicitly enabled.<ref>Nat Sakamura +5, ''OpenID Connect - Part 5: Self Issued Provider 1.0 - draft 00. deprecated, see [[OpenID Connect]] section 7'' (2013-08-25) OpenID Foundation https://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-selfissued-1_0.html</ref>
−
* [[Distributed ID]] is a somewhat different concept in that it envisions an identity which is broken into may pieces that are hosted by many different authorities and only brought together in a [[Relying Party]] upon [[User Consent]].
+
* [[Distributed ID]] is a somewhat different concept in that it envisions an identity which is broken into may pieces that are hosted by many different authorities and only brought together in a [[Relying Party]] upon [[User Consent]]. The impact of that is to allow the user's [[Attribute]]s to be reference by the use with [[URL]]s that both point to the [[Attribute]]s as a part of a Token that authorizes access by the [[Relying Party]].
−
* The current paradigm in open identity is for each conforming [[Relying Party]] to provide a list of [[Identifier or Attribute Provider]]s that the [[User]] could chose from to allow access.
+
* The current common paradigm in open identity is for each conforming [[Relying Party]] to provide a list of [[Identifier or Attribute Provider]]s that the [[User]] could chose from to allow access.
−
 
+
* If the input identifier for the discovery process contains the domain self-issued.me, dynamic discovery is not performed. Instead the following static values are used.
 +
  {
 +
  "authorization_endpoint":
 +
    "openid:",
 +
  "issuer":
 +
    "https://self-issued.me",
 +
  "scopes_supported":
 +
    ["openid", "profile", "email", "address", "phone"],
 +
  "response_types_supported":
 +
    ["id_token"],
 +
  "subject_types_supported":
 +
    ["pairwise"],
 +
  "id_token_signing_alg_values_supported":
 +
    ["RS256"],
 +
  "request_object_signing_alg_values_supported":
 +
    ["none", "RS256"]
 +
  }
 +
* The certificate on https://self-issued.me/registration/1.0/  has been revoked, so that cannot be used for testing at this time.
  
 
==Problems==
 
==Problems==
−
* The big problem is [[Trust]] where there are no standards or examples of any trust without a history of trusted behavior.
+
* The big problem with any sort of [[Self-issued Identifier]] is [[Trust]] where there are no standards or examples of any trust without a history of trusted behavior.
−
 
+
* One big problem with the [[OpenID Connect]] flow for a [[Self-issued Identifier]] is that there is no validation of the request for user information.
 +
* Another is the lack of any security over the registration for the URL capture.
 +
* A very big problem with many user issued identities is the loss on context. In other words, the use cannot be expected to remember which ID was used for any length of time.
 +
* Perhaps the biggest problem with user control if identifiers is protecting the authentication secrets and allow user recovery of lost authentication factors.
  
 
==Solutions==
 
==Solutions==
 +
*Define the process of creating a DID URL for the [[Self-issued Identifier]].
 +
*Create resolver code that could be called by any sort of [[Universal Resolver]] or [[Trusted Resolver]] in the DID space.
 +
*Build [[Native App]]s using [[Native App URI Handlers]] for Android, IoS and Windows to act as [[Identifier or Attribute Provider]]s.
 
*The Decentralized Identity Foundation has been created to enable "an open source decentralized identity ecosystem for people, organizations, apps, and devices". The have a list of areas of interest<ref>Decentralized Identity Foundation working groups http://identity.foundation/working-groups</ref> that include block-chain and universal discovery which seem to be diametrically opposite of [[Privacy]] legislation like the [[GDPR]] and [[California Consumer Privacy Act of 2018]].
 
*The Decentralized Identity Foundation has been created to enable "an open source decentralized identity ecosystem for people, organizations, apps, and devices". The have a list of areas of interest<ref>Decentralized Identity Foundation working groups http://identity.foundation/working-groups</ref> that include block-chain and universal discovery which seem to be diametrically opposite of [[Privacy]] legislation like the [[GDPR]] and [[California Consumer Privacy Act of 2018]].
 +
*Nat Sakamura [https://www.youtube.com/watch?v=tTeN_SxQ_OI presentation on creating a] [[Self-issued Identifier]] provider.
 +
===Example Control Flow===
 +
[[file:SII-SSI.png]]
 +
#GET - user navigates to a restricted resource
 +
#Not Auth - the [[Relying Party]] does not recognize the user and responds with information about itself to the user together with the [[User Information]] (Scopes) that it needs.
 +
#Redir - The browser recognizes the type of [[Identifier]] that was selected and redirects the request to a [[User Agent]] that can process the request.
 +
#Who is this guy - The UA sends a request to an appropriate [[Trust Registry]]
 +
#Good Guy - (cachable) If the RP is not known to the user agent, it requests data to be shown to the user.
 +
#Here's my Stuff - If the user consents, the request information that is approved by the user is sent to the RP which gets the data in its Customer Relationship Manager (CRM).
 +
#Good to Go (cachable) - The CRM recognizes the user (or perhaps asks the user for more information) and then sends the [[Authorization]] to the user (typically a cookie).
 +
#GET (continued) - the user is now able to access the resource that was the reason for the original GET.
 +
 +
===Example Authorization===
 +
* This is a Successful Authentication Response as defined in [[OpenID Connect]] for implicit flow. Meaning a flow that sends all results in the first response without having to first acquire a access code.
 +
*When using the Implicit Flow, Authentication Responses are made in the same manner as for the Authorization Code Flow, as defined in Section 3.1.2.5, with the exception of the differences specified in this section.
 +
*When using the Implicit Flow, all response parameters are added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was specified.
 +
 +
These parameters are returned from the Authorization Endpoint:
 +
 +
* access_token OAuth 2.0 Access Token. This is returned unless the response_type value used is id_token.
 +
* token_type OAuth 2.0 Token Type value. The value MUST be Bearer or another token_type value that the Client has negotiated with the Authorization Server. Clients implementing this profile MUST support the OAuth 2.0 Bearer Token Usage [RFC6750] specification. This profile only describes the use of bearer tokens. This is returned in the same cases as access_token is.
 +
* id_token REQUIRED. ID Token.
 +
* state OAuth 2.0 state value. REQUIRED if the state parameter is present in the Authorization Request. Clients MUST verify that the state value is equal to the value of state parameter in the Authorization Request.
 +
* expires_in OPTIONAL. Expiration time of the Access Token in seconds since the response was generated.
 +
* Per Section 4.2.2 of OAuth 2.0 [RFC6749], no code result is returned when using the Implicit Flow.
  
 +
The following is a non-normative example of a successful response using the Implicit Flow (with line wraps for the display purposes only) This shows the response as a URL fragment since the query response mode is discouraged. Unfortunately fragment are not accepted by all servers from client, so this is not a practical solution. In the short term query response are accepted. In the long term a POST response is best.
 +
<PRE>
 +
  HTTP/1.1 302 Found
 +
  Location: https://client.example.org/cb#
 +
    access_token=SlAV32hkKG
 +
    &token_type=bearer
 +
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
 +
    &expires_in=3600
 +
    &state=af0ifjsldkj
 +
</PRE>
  
 
==References==
 
==References==
Line 20: Line 78:
  
 
===Miscellaneous References===
 
===Miscellaneous References===
 +
* wiki page on [[Self-issued OpenID Provider]]
 +
* wiki page on [[Self-Sovereign Identity]]
 +
* [http://self-issued.info/?p=2013 Using OpenID Connect Self-Issued to Achieve DID Auth] from Mike Jones
 +
*[https://security.stackexchange.com/questions/150649/who-is-the-special-openid-connect-url-self-issued-me-issued-to-and-is-it-a-ri Who is the special openid connect url issued to and is it a risk?] http://self-issued.me
  
  
 
[[Category:Glossary]]
 
[[Category:Glossary]]
 
[[Category:Authentication]]
 
[[Category:Authentication]]
 +
[[Category:Identifier]]

Latest revision as of 13:48, 9 August 2020

Full Title or Meme

When the Subject of an interchange is given the ability to create and manage their own Identifier and their own Identifier or Attribute Provider in support of those Identifiers and Attributes.

Context

  • As a part of the effort to create OpenID Connect the option for the Subject to issue their own Identifiers was explicitly enabled.[1]
  • Distributed ID is a somewhat different concept in that it envisions an identity which is broken into may pieces that are hosted by many different authorities and only brought together in a Relying Party upon User Consent. The impact of that is to allow the user's Attributes to be reference by the use with URLs that both point to the Attributes as a part of a Token that authorizes access by the Relying Party.
  • The current common paradigm in open identity is for each conforming Relying Party to provide a list of Identifier or Attribute Providers that the User could chose from to allow access.
  • If the input identifier for the discovery process contains the domain self-issued.me, dynamic discovery is not performed. Instead the following static values are used.
 {
  "authorization_endpoint":
    "openid:",
  "issuer":
    "https://self-issued.me",
  "scopes_supported":
    ["openid", "profile", "email", "address", "phone"],
  "response_types_supported":
    ["id_token"],
  "subject_types_supported":
    ["pairwise"],
  "id_token_signing_alg_values_supported":
    ["RS256"],
  "request_object_signing_alg_values_supported":
    ["none", "RS256"]
 }

Problems

  • The big problem with any sort of Self-issued Identifier is Trust where there are no standards or examples of any trust without a history of trusted behavior.
  • One big problem with the OpenID Connect flow for a Self-issued Identifier is that there is no validation of the request for user information.
  • Another is the lack of any security over the registration for the URL capture.
  • A very big problem with many user issued identities is the loss on context. In other words, the use cannot be expected to remember which ID was used for any length of time.
  • Perhaps the biggest problem with user control if identifiers is protecting the authentication secrets and allow user recovery of lost authentication factors.

Solutions

Example Control Flow

SII-SSI.png

  1. GET - user navigates to a restricted resource
  2. Not Auth - the Relying Party does not recognize the user and responds with information about itself to the user together with the User Information (Scopes) that it needs.
  3. Redir - The browser recognizes the type of Identifier that was selected and redirects the request to a User Agent that can process the request.
  4. Who is this guy - The UA sends a request to an appropriate Trust Registry
  5. Good Guy - (cachable) If the RP is not known to the user agent, it requests data to be shown to the user.
  6. Here's my Stuff - If the user consents, the request information that is approved by the user is sent to the RP which gets the data in its Customer Relationship Manager (CRM).
  7. Good to Go (cachable) - The CRM recognizes the user (or perhaps asks the user for more information) and then sends the Authorization to the user (typically a cookie).
  8. GET (continued) - the user is now able to access the resource that was the reason for the original GET.

Example Authorization

  • This is a Successful Authentication Response as defined in OpenID Connect for implicit flow. Meaning a flow that sends all results in the first response without having to first acquire a access code.
  • When using the Implicit Flow, Authentication Responses are made in the same manner as for the Authorization Code Flow, as defined in Section 3.1.2.5, with the exception of the differences specified in this section.
  • When using the Implicit Flow, all response parameters are added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was specified.

These parameters are returned from the Authorization Endpoint:

  • access_token OAuth 2.0 Access Token. This is returned unless the response_type value used is id_token.
  • token_type OAuth 2.0 Token Type value. The value MUST be Bearer or another token_type value that the Client has negotiated with the Authorization Server. Clients implementing this profile MUST support the OAuth 2.0 Bearer Token Usage [RFC6750] specification. This profile only describes the use of bearer tokens. This is returned in the same cases as access_token is.
  • id_token REQUIRED. ID Token.
  • state OAuth 2.0 state value. REQUIRED if the state parameter is present in the Authorization Request. Clients MUST verify that the state value is equal to the value of state parameter in the Authorization Request.
  • expires_in OPTIONAL. Expiration time of the Access Token in seconds since the response was generated.
  • Per Section 4.2.2 of OAuth 2.0 [RFC6749], no code result is returned when using the Implicit Flow.

The following is a non-normative example of a successful response using the Implicit Flow (with line wraps for the display purposes only) This shows the response as a URL fragment since the query response mode is discouraged. Unfortunately fragment are not accepted by all servers from client, so this is not a practical solution. In the short term query response are accepted. In the long term a POST response is best. 

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj

References

  1. ↑ Nat Sakamura +5, OpenID Connect - Part 5: Self Issued Provider 1.0 - draft 00. deprecated, see OpenID Connect section 7 (2013-08-25) OpenID Foundation https://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-selfissued-1_0.html
  2. ↑ Decentralized Identity Foundation working groups http://identity.foundation/working-groups

Miscellaneous References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Self-issued_Identifier&oldid=7812"