Difference between revisions of "Self-issued Identifier"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Context)
Line 3: Line 3:
  
 
==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.'' (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]]. 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]].
 
* [[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 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.
 
* 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.

Revision as of 18:11, 16 February 2019

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.

Solutions

References

  1. Nat Sakamura +5, OpenID Connect - Part 5: Self Issued Provider 1.0 - draft 00. (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