Self-issued Identifier - Revision history

Tomjones: /* Context */

2020-07-25T23:37:07Z

Context

← Older revision		Revision as of 23:37, 25 July 2020
Line 4:		Line 4:
	==Context==		==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.		* 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 [https://www.w3.org/2019/did-wg/ W3C program] in conjunction with the Decentralized Identifier Foundation (DIF), there is a need for the [[Identity Ecosystem]] to coordinate with other teams developing this technology.		* With the rise of the [https://www.w3.org/2019/did-wg/ W3C program] in conjunction with the [https://identity.foundation/ Decentralized Identifier Foundation (DIF)], 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.		* At the 2020-06-16 meeting of the Kantara FIRE WG a liaison effort was approved. That effort is tracked here.
	* The document is being created in conjunction with the DIF starting on 2020-07-20. After this group and the DIF agree the document will be forwarded to the OpenID for consideration.		* The document is being created in conjunction with the DIF starting on 2020-07-20. After this group and the DIF agree the document will be forwarded to the OpenID for consideration.

Tomjones: /* Context */

2020-07-25T23:35:23Z

Context

← Older revision		Revision as of 23:35, 25 July 2020
Line 4:		Line 4:
	==Context==		==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.		* 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 [https://www.w3.org/2019/did-wg/ W3C program] on Decentralized ~~Identifiers~~, there is a need for the [[Identity Ecosystem]] to coordinate with other teams developing this technology.		* With the rise of the [https://www.w3.org/2019/did-wg/ W3C program] in conjunction with the Decentralized Identifier Foundation (DIF), 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.		* At the 2020-06-16 meeting of the Kantara FIRE WG a liaison effort was approved. That effort is tracked here.
	* At the 2020-06-~~18 meeting of~~ the ~~OpenID AB/C WG it seemed like a summary of~~ the ~~various points would help~~ to ~~reach a consensus approach~~.		* The document is being created in conjunction with the DIF starting on 2020-07-20. After this group and the DIF agree the document will be forwarded to the OpenID for consideration.

	===History===		===History===
	* The [[https://openid.net/specs/openid-connect-core-1_0.html OpenID Connect Core 1.0] was issued on 2018-11-08 with section 7 covering self-issued ID. Initial uptake was minimal.		* The [[https://openid.net/specs/openid-connect-core-1_0.html OpenID Connect Core 1.0] was issued on 2018-11-08 with section 7 covering self-issued ID. Initial uptake was minimal.

Tomjones at 23:27, 25 July 2020

2020-07-25T23:27:56Z

← Older revision		Revision as of 23:27, 25 July 2020
Line 14:		Line 14:
	* Recently the DIF posted [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] which leaves the issue of sub alone and create a new field for the DID only.		* Recently the DIF posted [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] which leaves the issue of sub alone and create a new field for the DID only.
	* On 2020-06-06 a proposal was posted to "[https://bitbucket.org/openid/connect/issues/1175/create-a-separate-spec-for-self-issued Create a Separate Spec for Self-Issued Identifiers"] that would address the issues about sub and a persistent ID in the context of the problem of key recovery, reissue and roll-over while giving the user a better experience with OpenID Connect.		* On 2020-06-06 a proposal was posted to "[https://bitbucket.org/openid/connect/issues/1175/create-a-separate-spec-for-self-issued Create a Separate Spec for Self-Issued Identifiers"] that would address the issues about sub and a persistent ID in the context of the problem of key recovery, reissue and roll-over while giving the user a better experience with OpenID Connect.
			* On 2020-07-20 OpenID core agreed to create a document for review which is posted at: [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile]

	==Problems==		==Problems==

Tomjones: /* References */

2020-07-07T03:14:39Z

References

← Older revision		Revision as of 03:14, 7 July 2020
Line 33:		Line 33:
	* [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] of the Decentralized Identifier Foundation.		* [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] of the Decentralized Identifier Foundation.
			* [https://hackmd.io/1RBWM2yhQDiOSAdtjEuIRw?both SIOP laundry list] of future work items.
	* [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]

Tomjones: /* Solutions */

2020-06-22T22:46:56Z

Solutions

← Older revision		Revision as of 22:46, 22 June 2020
Line 28:		Line 28:
	## Any new identifier format (like the DID) should fit within the definition of this field as would new or propriety methods.		## 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.		## The id_token could be further described for optional Client Bound End-User Assertion (see reference below) in place of the traditional Bearer Token.
			# Specification of a token bound to the the creator and receiver. (e.g. Client Bound End user assertion.)

	==References==		==References==

Tomjones: /* Problems */

2020-06-22T20:40:34Z

Problems

← Older revision		Revision as of 20:40, 22 June 2020
Line 16:		Line 16:

	==Problems==		==Problems==
	* The current work of the Decentralized Identifiers has proceed with little ~~concern~~ for how it might interoperate with existing [[Identity Ecosystem]]s.		* The current work of the Decentralized Identifiers has proceed with little attention for how it might interoperate with existing [[Identity Ecosystem]]s.
	* The DIF SIOP spec creates a new fields for identifiers rather than fit within a common field that would promote interoperability with other methods.		* The DIF SIOP spec creates a new fields for identifiers rather than fit within a common field that would promote interoperability with other methods.
	* 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.		* 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.

Tomjones: /* Solutions */

2020-06-18T21:17:38Z

Solutions

← Older revision		Revision as of 21:17, 18 June 2020
Line 24:		Line 24:

	==Solutions==		==Solutions==
	# The Subject ID (sub) could be freed from the limitations described the core spec above and take its traditional unstructured format. This would allow it to take on any form, like that of a DID.		# The Subject ID (sub) could be freed from the limitations described the core spec above and take its traditional unstructured format. This would allow it to take on any form, like that of a DID or a GUID.
	# 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.		# 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.		## Any new identifier format (like the DID) should fit within the definition of this field as would new or propriety methods.

Tomjones: /* Problems */

2020-06-18T21:17:03Z

Problems

← Older revision		Revision as of 21:17, 18 June 2020
Line 21:		Line 21:
	* If the user's hardware device is stolen or disabled, the recovery of the user's identifier can be a challenge which could turn into a UX nightmare if not handled well.		* If the user's hardware device is stolen or disabled, the recovery 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.		* 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.
	* The current draft of the [~~Self-Issued OpenID Connect Provider DID Profile~~ Kantara FIRE DIA spec] treats the sub field as a random GUID to assure uniqueness.		* The current draft of the [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations Kantara FIRE DIA spec] treats the sub field as a random GUID to assure uniqueness.

	==Solutions==		==Solutions==

Tomjones: /* Problems */

2020-06-18T21:16:34Z

Problems

← Older revision		Revision as of 21:16, 18 June 2020
Line 21:		Line 21:
	* If the user's hardware device is stolen or disabled, the recovery of the user's identifier can be a challenge which could turn into a UX nightmare if not handled well.		* If the user's hardware device is stolen or disabled, the recovery 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.		* 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.
	* The current draft of the Kantara FIRE DIA spec treats the sub field as a random GUID to assure uniqueness.		* The current draft of the [Self-Issued OpenID Connect Provider DID Profile Kantara FIRE DIA spec] treats the sub field as a random GUID to assure uniqueness.

	==Solutions==		==Solutions==

Tomjones: /* Problems */

2020-06-18T21:15:38Z

Problems

← Older revision		Revision as of 21:15, 18 June 2020
Line 21:		Line 21:
	* If the user's hardware device is stolen or disabled, the recovery of the user's identifier can be a challenge which could turn into a UX nightmare if not handled well.		* If the user's hardware device is stolen or disabled, the recovery 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.		* 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.
			* The current draft of the Kantara FIRE DIA spec treats the sub field as a random GUID to assure uniqueness.

	==Solutions==		==Solutions==