High Assurance AZ Token - Revision history

Tomjones: /* Scope/Goals */

2020-07-24T19:23:48Z

Scope/Goals

← Older revision		Revision as of 19:23, 24 July 2020
Line 12:		Line 12:
	# a document that can be sent to a web site that is requesting access to user controlled resources.		# a document that can be sent to a web site that is requesting access to user controlled resources.
	# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.		# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.
	# Track and absorb the good ideas of OpenID Consent and the IETF [[OAuth 2]] and [[GNAP]] with a goal of the highest possible level of compatibility.		# Track and absorb the good ideas of OpenID Consent and the IETF [[OAuth 2.0]] and [[GNAP]] with a goal of the highest possible level of compatibility.

	==Context==		==Context==

Tomjones: /* Scope/Goals */

2020-07-24T19:21:04Z

Scope/Goals

← Older revision		Revision as of 19:21, 24 July 2020
Line 12:		Line 12:
	# a document that can be sent to a web site that is requesting access to user controlled resources.		# a document that can be sent to a web site that is requesting access to user controlled resources.
	# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.		# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.
	# Track and absorb the good ideas of OpenID Consent and the IETF [[OAuth 2]] and [[GNAP]]		# Track and absorb the good ideas of OpenID Consent and the IETF [[OAuth 2]] and [[GNAP]] with a goal of the highest possible level of compatibility.

	==Context==		==Context==

Tomjones: /* Scope/Goals */

2020-07-24T19:20:12Z

Scope/Goals

← Older revision		Revision as of 19:20, 24 July 2020
Line 12:		Line 12:
	# a document that can be sent to a web site that is requesting access to user controlled resources.		# a document that can be sent to a web site that is requesting access to user controlled resources.
	# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.		# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.
			# Track and absorb the good ideas of OpenID Consent and the IETF [[OAuth 2]] and [[GNAP]]

	==Context==		==Context==

Tomjones: /* Nomenclature */

2020-07-24T19:16:22Z

Nomenclature

← Older revision		Revision as of 19:16, 24 July 2020
Line 8:		Line 8:
	* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ Grant Negotiation and Authorization Protocol (GNAP) is a new effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.		* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ Grant Negotiation and Authorization Protocol (GNAP) is a new effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.
	* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization. But it could also just be labeled as a consent token.		* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization. But it could also just be labeled as a consent token.

			===Scope/Goals===
			# a document that can be sent to a web site that is requesting access to user controlled resources.
			# A document that can hold data or references to acquire that data to be sent to the requestor based on the request and the user's consent.

	==Context==		==Context==

Tomjones: /* Nomenclature */

2020-07-05T03:18:48Z

Nomenclature

← Older revision		Revision as of 03:18, 5 July 2020
Line 7:		Line 7:
	* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.		* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
	* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ Grant Negotiation and Authorization Protocol (GNAP) is a new effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.		* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ Grant Negotiation and Authorization Protocol (GNAP) is a new effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.
	* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization.		* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization. But it could also just be labeled as a consent token.

	==Context==		==Context==

Tomjones: /* Nomenclature */

2020-07-05T03:17:30Z

Nomenclature

← Older revision		Revision as of 03:17, 5 July 2020
Line 6:		Line 6:
	* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.		* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.
	* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.		* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
	* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ GNAP is ~~an ongoing~~ effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.		* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ Grant Negotiation and Authorization Protocol (GNAP) is a new effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.
	* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization.		* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization.

Tomjones: /* Nomenclature */

2020-07-05T03:15:50Z

Nomenclature

← Older revision		Revision as of 03:15, 5 July 2020
Line 7:		Line 7:
	* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.		* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
	* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ GNAP is an ongoing effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.		* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ GNAP is an ongoing effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.
	* ~~The current~~ effort ~~(2020-05-08 [https://datatracker.ietf.org/wg/txauth/about/ Transactional Authorization and Delegation (txauth)])~~ to create a new AZ Token ~~is having trouble find~~ a name ~~for this creature as OAuth no longer seems to fit the current needs~~. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.		* While the TXAuth in their effort to create a new AZ Token (morphing into the GNAP above) was struggling to get a new name several interesting ideas were floated. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource. Perhaps we can reuse that name in Kantara efforts. IXAuth might be a stand-in name for what the token described here provides; meaning Intentional Transaction for Authorization.
	* IXAuth might be a stand-in name for what the token described here ~~supports~~; meaning ~~Individual~~ Transaction for Authorization.

	==Context==		==Context==

Tomjones: /* Nomenclature */

2020-07-05T03:11:16Z

Nomenclature

← Older revision		Revision as of 03:11, 5 July 2020
Line 6:		Line 6:
	* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.		* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.
	* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.		* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
	* ~~TXAuth~~ is an ongoing effort in the IETF to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining ~~Troglodyte Transaction Authorization~~.		* [https://mailarchive.ietf.org/arch/msg/ietf-announce/afYBtwSr79TXcAhCoO4IXo1ePUg/ GNAP is an ongoing effort in the IETF] to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining the past rather than the future.
	* The current effort (2020-05-08 [https://datatracker.ietf.org/wg/txauth/about/ Transactional Authorization and Delegation (txauth)]) to create a new AZ Token is having trouble find a name for this creature as OAuth no longer seems to fit the current needs. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.		* The current effort (2020-05-08 [https://datatracker.ietf.org/wg/txauth/about/ Transactional Authorization and Delegation (txauth)]) to create a new AZ Token is having trouble find a name for this creature as OAuth no longer seems to fit the current needs. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.
	* IXAuth might be a stand-in name for what the token described here supports; meaning Individual Transaction for Authorization.		* IXAuth might be a stand-in name for what the token described here supports; meaning Individual Transaction for Authorization.

Tomjones: /* Nomenclature */

2020-07-05T03:06:34Z

Nomenclature

← Older revision		Revision as of 03:06, 5 July 2020
Line 6:		Line 6:
	* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.		* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.
	* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.		* [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials] are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
	* TXAuth is an ongoing effort to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining Troglodyte Transaction Authorization.		* TXAuth is an ongoing effort in the IETF to create a new version to replace [[OAuth 2.0]]. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining Troglodyte Transaction Authorization.
	* The current effort (2020-05-08 [https://datatracker.ietf.org/wg/txauth/about/ Transactional Authorization and Delegation (txauth)]) to create a new AZ Token is having trouble find a name for this creature as OAuth no longer seems to fit the current needs. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.		* The current effort (2020-05-08 [https://datatracker.ietf.org/wg/txauth/about/ Transactional Authorization and Delegation (txauth)]) to create a new AZ Token is having trouble find a name for this creature as OAuth no longer seems to fit the current needs. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.
	* IXAuth might be a stand-in name for what the token described here supports; meaning Individual Transaction for Authorization.		* IXAuth might be a stand-in name for what the token described here supports; meaning Individual Transaction for Authorization.

Tomjones: /* Nomenclature */

2020-07-05T03:05:04Z

Nomenclature

← Older revision		Revision as of 03:05, 5 July 2020
Line 2:		Line 2:
	Ensure the security of a stand-alone Token to provide high assurance of (1) Identity, (2) Authentication and (3) Federation in high volume, universally accessible web services.		Ensure the security of a stand-alone Token to provide high assurance of (1) Identity, (2) Authentication and (3) Federation in high volume, universally accessible web services.
	===Nomenclature===		===Nomenclature===
	What’s in a name? That which we call a rose, by any other name would smell as sweet. (Shakespeare) A lot of discussion has been focused on the adjective to use the [[Authorization]] Tokens, when the problem is that these tokens provide information, not authorization. The information may come in the form of verified claims, but it is up the the resource server to evaluate the claims before authorizing access to the resource. (Another way to ~~assert~~ this is that, in the end, all authorization is local.)		What’s in a name? That which we call a rose, by any other name would smell as sweet. (Shakespeare) A lot of discussion has been focused on the adjective to use the [[Authorization]] Tokens, when the problem is that these tokens provide information, not authorization. The information may come in the form of verified claims, but it is up the the resource server to evaluate the claims before authorizing access to the resource. (Another way to frame this statement is that, in the end, all authorization is local.)
	* This token is named an [[Authorization]] token in conformance the [[OAuth 2.0]] usage not because it actually authorizes any action. It should, however, carry all of the [[Authorization]] information needed by the [[Resource Server]] to grant access to the protected resource.		* This token is named an [[Authorization]] token in conformance the [[OAuth 2.0]] usage not because it actually authorizes any action. It should, however, carry all of the [[Authorization]] information needed by the [[Resource Server]] to grant access to the protected resource.
	* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.		* JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS can also refer to the jose token signed by an entity that can validate the token.