< draft-hardt-xauth-protocol-12.txt		draft-hardt-xauth-protocol-13.txt >
	Network Working Group D. Hardt, Ed.		Network Working Group D. Hardt, Ed.
	Internet-Draft SignIn.Org		Internet-Draft SignIn.Org
	Intended status: Standards Track 8 July 2020		Intended status: Standards Track 13 July 2020
	Expires: 9 January 2021		Expires: 14 January 2021
	The Grant Negotiation and Authorization Protocol		The Grant Negotiation and Authorization Protocol
	draft-hardt-xauth-protocol-12		draft-hardt-xauth-protocol-13
	Abstract		Abstract
	Client software often desires resources or identity claims that are		Client software often desires resources or identity claims that are
	independent of the client. This protocol allows a user and/or		independent of the client. This protocol allows a user and/or
	resource owner to delegate resource authorization and/or release of		resource owner to delegate resource authorization and/or release of
	identity claims to a server. Client software can then request access		identity claims to a server. Client software can then request access
	to resources and/or identity claims by calling the server. The		to resources and/or identity claims by calling the server. The
	server acquires consent and authorization from the user and/or		server acquires consent and authorization from the user and/or
	resource owner if required, and then returns to the client software		resource owner if required, and then returns to the client software
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 9 January 2021.		This Internet-Draft will expire on 14 January 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	3.1. GS API Table . . . . . . . . . . . . . . . . . . . . . . 12		3.1. GS API Table . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Create Grant . . . . . . . . . . . . . . . . . . . . . . 12		3.2. Create Grant . . . . . . . . . . . . . . . . . . . . . . 12
	3.3. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 15		3.3. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 15
	3.4. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 16		3.4. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 16
	3.5. Request JSON . . . . . . . . . . . . . . . . . . . . . . 16		3.5. Request JSON . . . . . . . . . . . . . . . . . . . . . . 16
	3.5.1. "client" Object . . . . . . . . . . . . . . . . . . . 17		3.5.1. "client" Object . . . . . . . . . . . . . . . . . . . 17
	3.5.2. "interaction" Object . . . . . . . . . . . . . . . . 17		3.5.2. "interaction" Object . . . . . . . . . . . . . . . . 17
	3.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 18		3.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 18
	3.5.4. "authorizations" Object . . . . . . . . . . . . . . . 18		3.5.4. "authorizations" Object . . . . . . . . . . . . . . . 18
	3.5.5. Authorization Request Object . . . . . . . . . . . . 18		3.5.5. Authorization Request Object . . . . . . . . . . . . 18
	3.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 19		3.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 18
	3.6. Read Authorization . . . . . . . . . . . . . . . . . . . 19		3.6. Read Authorization . . . . . . . . . . . . . . . . . . . 19
	3.7. GS Options . . . . . . . . . . . . . . . . . . . . . . . 19		3.7. GS Options . . . . . . . . . . . . . . . . . . . . . . . 19
	4. GS Responses . . . . . . . . . . . . . . . . . . . . . . . . 20		4. GS Responses . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 20		4.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 20
	4.2. Interaction Response . . . . . . . . . . . . . . . . . . 22		4.2. Interaction Response . . . . . . . . . . . . . . . . . . 22
	4.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 23		4.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 22
	4.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 23		4.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 23
	4.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 23		4.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 23
	4.4.2. "interaction" Object . . . . . . . . . . . . . . . . 24		4.4.2. "interaction" Object . . . . . . . . . . . . . . . . 23
	4.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 24		4.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 23
	4.4.4. "authorizations" Object . . . . . . . . . . . . . . . 24		4.4.4. "authorizations" Object . . . . . . . . . . . . . . . 24
	4.4.5. Authorization response Object . . . . . . . . . . . . 24		4.4.5. Authorization response Object . . . . . . . . . . . . 24
	4.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 24		4.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 24
	4.4.7. "warnings" JSON Array . . . . . . . . . . . . . . . . 25		4.4.7. "warnings" JSON Array . . . . . . . . . . . . . . . . 25
	4.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 25		4.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 25
	4.6. Response Verification . . . . . . . . . . . . . . . . . . 26		4.6. Response Verification . . . . . . . . . . . . . . . . . . 26
	5. Interaction Modes . . . . . . . . . . . . . . . . . . . . . . 26		5. Interaction Modes . . . . . . . . . . . . . . . . . . . . . . 26
	5.1. "redirect" . . . . . . . . . . . . . . . . . . . . . . . 26		5.1. "redirect" . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1.1. "redirect" verification . . . . . . . . . . . . . . . 27		5.1.1. "redirect" verification . . . . . . . . . . . . . . . 27
	5.2. "indirect" . . . . . . . . . . . . . . . . . . . . . . . 27		5.2. "indirect" . . . . . . . . . . . . . . . . . . . . . . . 27
	5.3. "user_code" . . . . . . . . . . . . . . . . . . . . . . . 28		5.3. "user_code" . . . . . . . . . . . . . . . . . . . . . . . 27
	6. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 28		6. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 28		7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 28
	8. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 28		8. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28
	10. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 30		10. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 32		13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	14.1. Normative References . . . . . . . . . . . . . . . . . . 32		14.1. Normative References . . . . . . . . . . . . . . . . . . 32
	14.2. Informative References . . . . . . . . . . . . . . . . . 34		14.2. Informative References . . . . . . . . . . . . . . . . . 34
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 34		Appendix A. Document History . . . . . . . . . . . . . . . . . . 34
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 34		A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 34
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 35		A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 35
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 35		A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 35
	A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 35		A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 35
	A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 36		A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 36
	A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 36		A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 36
	A.8. draft-hardt-xauth-protocol-07 . . . . . . . . . . . . . . 36		A.8. draft-hardt-xauth-protocol-07 . . . . . . . . . . . . . . 36
	A.9. draft-hardt-xauth-protocol-08 . . . . . . . . . . . . . . 36		A.9. draft-hardt-xauth-protocol-08 . . . . . . . . . . . . . . 36
	A.10. draft-hardt-xauth-protocol-09 . . . . . . . . . . . . . . 36		A.10. draft-hardt-xauth-protocol-09 . . . . . . . . . . . . . . 36
	A.11. draft-hardt-xauth-protocol-10 . . . . . . . . . . . . . . 37		A.11. draft-hardt-xauth-protocol-10 . . . . . . . . . . . . . . 37
	A.12. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 37		A.12. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 37
	A.13. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 37		A.13. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 37
			A.14. draft-hardt-xauth-protocol-12 . . . . . . . . . . . . . . 37
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 37		Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 37
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	*EDITOR NOTE*		*EDITOR NOTE*
	_This document captures a number of concepts that may be adopted by		_This document captures a number of concepts that may be adopted by
	the proposed GNAP working group. Please refer to this document as:_		the proposed GNAP working group. Please refer to this document as:_
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	2.1. "redirect" Interaction		2.1. "redirect" Interaction
	The Client is a web application and wants a Grant from the User:		The Client is a web application and wants a Grant from the User:
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| | +------+		| |<--- Interaction Response ---(2)--| | +------+
	| | | | | User |		| | | | | User |
	| |--(3)--- Interaction Transfer --- | - - - | ------->| |		| |--(3)--- Interaction Transfer --- | - - - | ------->| (RO) |
	| | | |<--(4)-->| |		| | | |<--(4)-->| |
	| | | | authN | |		| | | | authN | |
	| | | | | |		| | | | | |
	| | | |<--(5)-->| |		| | | |<--(5)-->| |
	| | | | authZ | |		| | | | authZ | |
	| |<--- Interaction Transfer ---(6)- | - - - | --------| |		| |<--- Interaction Transfer ---(6)- | - - - | --------| |
	| | | | | |		| | | | | |
	| |--(7)--- Verify Grant ----------->| | +------+		| |--(7)--- Verify Grant ----------->| | +------+
	| | | |		| | | |
	| |<--------- Grant Response ---(8)--| |		| |<--------- Grant Response ---(8)--| |
	skipping to change at page 8, line 51 ¶		skipping to change at page 8, line 51 ¶
	the User is required and sends an Interaction Response		the User is required and sends an Interaction Response
	(Section 4.2) containing the Grant URI and an		(Section 4.2) containing the Grant URI and an
	interaction.redirect object.		interaction.redirect object.
	3. *Interaction Transfer* The Client redirects the User to the		3. *Interaction Transfer* The Client redirects the User to the
	redirect_uri at the GS.		redirect_uri at the GS.
	4. *User Authentication* The GS authenticates the User.		4. *User Authentication* The GS authenticates the User.
	5. *User Authorization* If required, the GS interacts with the User		5. *User Authorization* If required, the GS interacts with the User
	to determine which identity claims and/or authorizations in the		(who is also the RO) to determine which identity claims and/or
	Grant Request are to be granted.		authorizations in the Grant Request are to be granted.
	6. *Interaction Transfer* The GS redirects the User to the		6. *Interaction Transfer* The GS redirects the User to the
	completion_uri at the Client.		completion_uri at the Client.
	7. *Verify Grant* The Client makes an HTTP PATCH request to the		7. *Verify Grant* The Client makes an HTTP PATCH request to the
	Grant URI passing the verification code (Section 3.3).		Grant URI passing the verification code (Section 3.3).
	8. *Grant Response* The GS responds with a Grant Response		8. *Grant Response* The GS responds with a Grant Response
	(Section 4.1).		(Section 4.1).
	2.2. "user_code" Interaction		2.2. "user_code" Interaction
	A Client is on a device wants a Grant from the User:		A Client is on a device wants a Grant from the User:
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| | +------+		| |<--- Interaction Response ---(2)--| | +------+
	| | | | | User |		| | | | | User |
	| |--(3)--- Read Grant ------------->| | | |		| |--(3)--- Read Grant ------------->| | | (RO) |
	| | | |<--(4)-->| |		| | | |<--(4)-->| |
	| | | | authN | |		| | | | authN | |
	| | | | | |		| | | | | |
	| | | |<--(5)---| |		| | | |<--(5)---| |
	| | | | code | |		| | | | code | |
	| | | | | |		| | | | | |
	| | | |<--(6)-->| |		| | | |<--(6)-->| |
	| | | | authZ | |		| | | | authZ | |
	| | | | | |		| | | | | |
	| |<--------- Grant Response ---(7)--| | | |		| |<--------- Grant Response ---(7)--| | | |
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 14 ¶
	3. *Read Grant* The Client makes an HTTP GET request to the Grant		3. *Read Grant* The Client makes an HTTP GET request to the Grant
	URI.		URI.
	4. *User Authentication* The User loads display_uri in their		4. *User Authentication* The User loads display_uri in their
	browser, and the GS authenticates the User.		browser, and the GS authenticates the User.
	5. *User Code* The User enters the code at the GS.		5. *User Code* The User enters the code at the GS.
	6. *User Authorization* If required, the GS interacts with the User		6. *User Authorization* If required, the GS interacts with the User
	to determine which identity claims and/or authorizations in the		(who is also the RO) to determine which identity claims and/or
	Grant Request are to be granted.		authorizations in the Grant Request are to be granted.
	7. *Grant Response* The GS responds with a Grant Response		7. *Grant Response* The GS responds with a Grant Response
	(Section 4.1).		(Section 4.1).
	8. *Information URI Redirect* The GS redirects the User to the		8. *Information URI Redirect* The GS redirects the User to the
	information_uri provided by the Client.		information_uri provided by the Client.
	2.3. Independent RO Authorization		2.3. Independent RO Authorization
	The Client wants access to resources that require the GS to interact		The Client wants access to resources that require the GS to interact
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 29 ¶
	"user_code": {		"user_code": {
	"information_uri": "https://device.example/c/user_code"		"information_uri": "https://device.example/c/user_code"
	}		}
	},		},
	"authorizations": {		"authorizations": {
	"play_music": {		"play_music": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "play_music",		"scope" : "play_music",
	},		},
	"read_user_info: {		"read_user_info: {
	"type" : "oauth_rich",		"type" : "customer_information",
	"authorization_details" [		"locations": [
	{		"https://example.com/customers",
	"type": "customer_information",		]
	"locations": [		"actions": [
	"https://example.com/customers",		"read"
	]		],
	"actions": [		"datatypes": [
	"read"		"contacts",
	],		"photos"
	"datatypes": [
	"contacts",
	"photos"
	]
	}
	]		]
	}		}
	}		}
	}		}
			[Editor: the "oauth_scope" and "customer_information" types are not
			normative, but generally representative of what may be defined in
			[RAR].
	3.3. Verify Grant		3.3. Verify Grant
	The Client verifies a Grant by doing an HTTP PATCH of a JSON document		The Client verifies a Grant by doing an HTTP PATCH of a JSON document
	to the Grant URI. The Client MUST only verify a Grant once.		to the Grant URI. The Client MUST only verify a Grant once.
	The JSON document MUST include the following from the Request JSON		The JSON document MUST include the following from the Request JSON
	Section 3.5:		Section 3.5:
	* iat		* iat
	skipping to change at page 18, line 36 ¶		skipping to change at page 18, line 36 ¶
	Contains either an authorization request object, or key / value		Contains either an authorization request object, or key / value
	pairs, where each unique key is created by the client, and the value		pairs, where each unique key is created by the client, and the value
	is an authorization request object Section 3.5.5. The key value of		is an authorization request object Section 3.5.5. The key value of
	"type" is reserved and MUST not be used by the client. The GS		"type" is reserved and MUST not be used by the client. The GS
	detects the authorizations object contains an authorization request		detects the authorizations object contains an authorization request
	object by the presence of the "type" property.		object by the presence of the "type" property.
	3.5.5. Authorization Request Object		3.5.5. Authorization Request Object
	* *type* - one of the following values: "oauth_scope" or		* *type* - any of the types per [RAR]. The remaining properties are
	"oauth_rich". Extensions MAY define additional types, and the		dependent on the type.
	required attributes. This attribute is REQUIRED.
	* *scope* - a string containing the OAuth 2.0 scope per [RFC6749]
	section 3.3. MUST be included if type is "oauth_scope". MAY be
	included if type is "oauth_rich".
	* *authorization_details* - an authorization_details JSON array of		[Editor: in the example we made up the "oauth_scope" type as a way of
	objects per [RAR]. MUST be included if type is "oauth_rich".		using existing OAuth scopes.]
	MUST not be included if type is "oauth_scope"
	_[Editor: details may change as the RAR document evolves]_		[Editor: rather then using the "type" property to differentiate
			between singular and plural authorization requests, the authorization
			could be an array, which would allow multiple types to be included in
			a single authorization, per the latest {{RAR} document}, and
			detection is if authorizations contains an array(singular), or
			object(plural)]
	3.5.6. "claims" Object		3.5.6. "claims" Object
	Includes one or more of the following:		Includes one or more of the following:
	* *oidc* - an object that contains one or both of the following		* *oidc* - an object that contains one or both of the following
	objects:		objects:
	- *userinfo* - Claims that will be returned as a JSON object		- *userinfo* - Claims that will be returned as a JSON object
	skipping to change at page 20, line 22 ¶		skipping to change at page 20, line 16 ¶
	* *claims* - an object containing the identity claims the Client may		* *claims* - an object containing the identity claims the Client may
	request from the GS, if any, and what public keys the claims will		request from the GS, if any, and what public keys the claims will
	be signed with.		be signed with.
	- Details TBD		- Details TBD
	* *algorithms* - a JSON array of the cryptographic algorithms		* *algorithms* - a JSON array of the cryptographic algorithms
	supported by the GS. [details TBD]*		supported by the GS. [details TBD]*
	* *features* - an object containing feature support		* *features* - an object containing feature or extension support
	- *authorizations* - boolean indicating if a request for more
	than one authorization in a request is supported.
	or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 7.		from Error Responses Section 7.
	4. GS Responses		4. GS Responses
	There are three successful responses to a Grant Request: Grant		There are three successful responses to a Grant Request: Grant
	skipping to change at page 21, line 4 ¶		skipping to change at page 20, line 43 ¶
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	and MAY include the following from the Response JSON Section 4.4		and MAY include the following from the Response JSON Section 4.4
	* client.handle		* client.handle
	* authorization or authorizations
			* authorizations
	* claims		* claims
	* expires_in		* expires_in
	* warnings		* warnings
	Example non-normative Grant Response JSON document for Example 1 in		Example non-normative Grant Response JSON document for Example 1 in
	Section 3.2:		Section 3.2:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"uri" : "https://as.example/endpoint/grant/example1",		"uri" : "https://as.example/endpoint/grant/example1",
	"expires_in" : 300		"expires_in" : 300
	"authorizations": {		"authorizations": {
	"access": {		"access": {
	skipping to change at page 22, line 18 ¶		skipping to change at page 22, line 5 ¶
	"uri" : "https://as.example/endpoint/grant/example2",		"uri" : "https://as.example/endpoint/grant/example2",
	"authorizations": {		"authorizations": {
	"play_music": { "uri" : "https://as.example/endpoint/authz/example2" },		"play_music": { "uri" : "https://as.example/endpoint/authz/example2" },
	"read_user_info: { "uri" " "https://as.example/endpoint/authz/"}		"read_user_info: { "uri" " "https://as.example/endpoint/authz/"}
	}		}
	}		}
	Note in this example the GS only provided the AZ URIs, and Client		Note in this example the GS only provided the AZ URIs, and Client
	must acquire the Authorizations per Section 3.6		must acquire the Authorizations per Section 3.6
			[Editor: the Client needs to remember if it asked for a single, or
			multiple authorizations, as there is no crisp algorithm for
			differentiating between the responses]
	4.2. Interaction Response		4.2. Interaction Response
	The Interaction Response MUST include the following from the Response		The Interaction Response MUST include the following from the Response
	JSON Section 4.4		JSON Section 4.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	skipping to change at page 32, line 23 ¶		skipping to change at page 32, line 16 ¶
	be defined to resolve from a hostname to the GS URI.		be defined to resolve from a hostname to the GS URI.
	10. *Why is there a Verify Grant? The Client can protect itself		10. *Why is there a Verify Grant? The Client can protect itself
	from session fixation without it.*		from session fixation without it.*
	Client implementations may not always follow the best practices.		Client implementations may not always follow the best practices.
	The Verify Grant allows the GS to ensure there is not a session		The Verify Grant allows the GS to ensure there is not a session
	fixation as the instance of the Client making creating the Grant		fixation as the instance of the Client making creating the Grant
	is the one that gets the verification code in the redirect.		is the one that gets the verification code in the redirect.
			11. **Why use the [OIDC] claims rather than the [IANA_JWT] list of
			claims?
			The [IANA_JWT] claims include claims that are not identity
			claims, and [IANA_JWT] references the [OIDC] claims, and [OIDC]
			5.1 are only identity claims.
	11. Acknowledgments		11. Acknowledgments
	This draft derives many of its concepts from Justin Richer's		This draft derives many of its concepts from Justin Richer's
	Transactional Authorization draft [TxAuth].		Transactional Authorization draft [TxAuth].
	Additional thanks to Justin Richer and Annabelle Richard Backman for		Additional thanks to Justin Richer and Annabelle Richard Backman for
	their strong critique of earlier drafts.		their strong critique of earlier drafts.
	12. IANA Considerations		12. IANA Considerations
	skipping to change at page 34, line 44 ¶		skipping to change at page 34, line 44 ¶
	[QR_Code] "ISO/IEC 18004:2015 - Information technology - Automatic		[QR_Code] "ISO/IEC 18004:2015 - Information technology - Automatic
	identification and data capture techniques - QR Code bar		identification and data capture techniques - QR Code bar
	code symbology specification", February 2015,		code symbology specification", February 2015,
	<https://www.iso.org/standard/62021.html>.		<https://www.iso.org/standard/62021.html>.
	[TxAuth] Richer, J., "Transactional AuthN", December 2019,		[TxAuth] Richer, J., "Transactional AuthN", December 2019,
	<https://tools.ietf.org/html/draft-richer-transactional-		<https://tools.ietf.org/html/draft-richer-transactional-
	authz-04>.		authz-04>.
			[IANA_JWT] "JSON Web Token Claims", January 2015,
			<https://www.iana.org/assignments/jwt/jwt.xhtml>.
	Appendix A. Document History		Appendix A. Document History
	A.1. draft-hardt-xauth-protocol-00		A.1. draft-hardt-xauth-protocol-00
	* Initial version		* Initial version
	A.2. draft-hardt-xauth-protocol-01		A.2. draft-hardt-xauth-protocol-01
	* text clean up		* text clean up
	skipping to change at page 37, line 37 ¶		skipping to change at page 37, line 37 ¶
	* renamed http verb to method		* renamed http verb to method
	* added Verify Grant and verification parameters		* added Verify Grant and verification parameters
	A.13. draft-hardt-xauth-protocol-11		A.13. draft-hardt-xauth-protocol-11
	* removed authorization object, and made authorizations object		* removed authorization object, and made authorizations object
	polymorphic		polymorphic
			A.14. draft-hardt-xauth-protocol-12
			* added Q about referencing OIDC claims vs IANA JWT
			* made all authorizations be a RAR type as it provides the required
			flexibility, removed "oauth_rar" type
			* added RO to places where the RO and User are the same
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect		Appendix B. Comparison with OAuth 2.0 and OpenID Connect
	*Changed Features*		*Changed Features*
	The major changes between GNAP and OAuth 2.0 and OpenID Connect are:		The major changes between GNAP and OAuth 2.0 and OpenID Connect are:
	* The Client always uses a private asymetric key to authenticate to		* The Client always uses a private asymetric key to authenticate to
	the GS. There is no client secret. i		the GS. There is no client secret. i
	* The Client initiates the protocol by making a signed request		* The Client initiates the protocol by making a signed request
	directly to the GS instead of redirecting the User to the GS.		directly to the GS instead of redirecting the User to the GS.
	* The Client does not pass any parameters in redirecting the User to		* The Client does not pass any parameters in redirecting the User to
	the GS.		the GS.
	* The refresh_token has been replaced with a AZ URI that both		* The refresh_token has been replaced with an AZ URI that both
	represents the authorization, and is the URI for obtaining a fresh		represents the authorization, and is the URI for obtaining a fresh
	access token.		access token.
	* The Client can request identity claims to be returned independent		* The Client can request identity claims to be returned independent
	of the ID Token. There is no UserInfo endpoint to query claims as		of the ID Token.
	there is in OpenID Connect.
	* The GS URI is the token endpoint.		* The GS URI is the only static endpoint. All other URIs are
			dynamically generated. The Client does not need to register it's
			redirect URIs.
	*Preserved Features*		*Preserved Features*
	* GNAP reuses the scopes, Client IDs, and access tokens of OAuth		* GNAP reuses the scopes, Client IDs, and access tokens of OAuth
	2.0.		2.0.
	* GNAP reuses the Client IDs, Claims and ID Token of OpenID Connect.		* GNAP reuses the Client IDs, Claims and ID Token of OpenID Connect.
	* No change is required by the Client or the RS for accessing		* No change is required by the Client or the RS for accessing
	existing bearer token protected APIs.		existing bearer token protected APIs.
End of changes. 28 change blocks.
	52 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/