< draft-hardt-xauth-protocol-11.txt		draft-hardt-xauth-protocol-12.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 4 July 2020		Intended status: Standards Track 8 July 2020
	Expires: 5 January 2021		Expires: 9 January 2021
	The Grant Negotiation and Authorization Protocol		The Grant Negotiation and Authorization Protocol
	draft-hardt-xauth-protocol-11		draft-hardt-xauth-protocol-12
	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 5 January 2021.		This Internet-Draft will expire on 9 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 29 ¶		skipping to change at page 2, line 29 ¶
	2.3. Independent RO Authorization . . . . . . . . . . . . . . 10		2.3. Independent RO Authorization . . . . . . . . . . . . . . 10
	2.4. Resource Server Access . . . . . . . . . . . . . . . . . 11		2.4. Resource Server Access . . . . . . . . . . . . . . . . . 11
	3. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . . . . . . . . 17		3.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 18
	3.5.4. "authorization" Object . . . . . . . . . . . . . . . 18		3.5.4. "authorizations" Object . . . . . . . . . . . . . . . 18
	3.5.5. "authorizations" Object . . . . . . . . . . . . . . . 18		3.5.5. Authorization Request Object . . . . . . . . . . . . 18
	3.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 18		3.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . . . . . . . . . . . . . 21		4.2. Interaction Response . . . . . . . . . . . . . . . . . . 22
	4.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 22		4.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 23
	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 . . . . . . . . . . . . . . . . 23		4.4.2. "interaction" Object . . . . . . . . . . . . . . . . 24
	4.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 23		4.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 24
	4.4.4. "authorization" Object . . . . . . . . . . . . . . . 23		4.4.4. "authorizations" Object . . . . . . . . . . . . . . . 24
	4.4.5. "authorizations" 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 . . . . . . . . . . . . . . . . 24		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 . . . . . . . . . . . . . . . 26		5.1.1. "redirect" verification . . . . . . . . . . . . . . . 27
	5.2. "indirect" . . . . . . . . . . . . . . . . . . . . . . . 27		5.2. "indirect" . . . . . . . . . . . . . . . . . . . . . . . 27
	5.3. "user_code" . . . . . . . . . . . . . . . . . . . . . . . 27		5.3. "user_code" . . . . . . . . . . . . . . . . . . . . . . . 28
	6. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 28		6. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 28		7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 28
	8. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 28		8. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29
	10. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 29		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 . . . . . . . . . . . . . . . . . 33		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 . . . . . . . . . . . . . . 34		A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 35
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 35		A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 35
	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 . . . . . . . . . . . . . . 35		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 . . . . . . . . . . . . . . 36		A.11. draft-hardt-xauth-protocol-10 . . . . . . . . . . . . . . 37
	A.12. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 36		A.12. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 37
			A.13. draft-hardt-xauth-protocol-11 . . . . . . . . . . . . . . 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 11, line 44 ¶		skipping to change at page 11, line 44 ¶
	+--------+ +-------+		+--------+ +-------+
	1. *Resource Request* The Client accesses the RS with the access		1. *Resource Request* The Client accesses the RS with the access
	token per Section 6 and receives a response from the RS.		token per Section 6 and receives a response from the RS.
	2. *Resource Request* The Client attempts to access the RS, but		2. *Resource Request* The Client attempts to access the RS, but
	receives an error indicating the access token needs to be		receives an error indicating the access token needs to be
	refreshed.		refreshed.
	3. *Read AuthZ* The Client makes a Read AuthZ (Section 3.6) with an		3. *Read AuthZ* The Client makes a Read AuthZ (Section 3.6) with an
	HTTP GET to the AZ URI and receives an Response JSON		HTTP GET to the AZ URI and receives as Response JSON
	"authorization" object (Section 4.4.4) with a fresh access token.		"authorization" object (Section 4.4.5) with a fresh access token.
	3. GS APIs		3. GS APIs
	*Client Authentication*		*Client Authentication*
	All GS APIs except for GS Options require the Client to authenticate.		All GS APIs except for GS Options require the Client to authenticate.
	Authentication mechanisms include:		Authentication mechanisms include:
	* JOSE Authentication [JOSE_Authentication]		* JOSE Authentication [JOSE_Authentication]
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 4 ¶
	* method - MUST be "POST"		* method - MUST be "POST"
	* client		* client
	and MAY include the following from Request JSON Section 3.5		and MAY include the following from Request JSON Section 3.5
	* user		* user
	* interaction		* interaction
	* authorization or authorizations		* authorizations
	* claims		* claims
	The GS MUST respond with one of Grant Response Section 4.1,		The GS MUST respond with one of Grant Response Section 4.1,
	Interaction Response Section 4.2, Wait Response Section 4.3, or one		Interaction Response Section 4.2, Wait Response Section 4.3, or one
	of the following errors:		of the following errors:
	* TBD		* TBD
	from Error Responses Section 7.		from Error Responses Section 7.
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	}		}
	},		},
	"interaction": {		"interaction": {
	"redirect": {		"redirect": {
	"completion_uri" : "https://web.example/return"		"completion_uri" : "https://web.example/return"
	},		},
	"global" : {		"global" : {
	"ui_locals" : "de"		"ui_locals" : "de"
	}		}
	},		},
	"authorization": {		"authorizations": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_contacts"		"scope" : "read_contacts"
	},		},
	"claims": {		"claims": {
	"oidc": {		"oidc": {
	"id_token" : {		"id_token" : {
	"email" : { "essential" : true },		"email" : { "essential" : true },
	"email_verified" : { "essential" : true }		"email_verified" : { "essential" : true }
	},		},
	"userinfo" : {		"userinfo" : {
	"name" : { "essential" : true },		"name" : { "essential" : true },
	"picture" : null		"picture" : null
	}		}
	}		}
	}		}
	}		}
	Following is a non-normative example of a device Client requesting		Following is a non-normative example of a device Client requesting
	access to play music using "oauth_rich":		two different access tokens, one request with "oauth_scope", the
			other with "oauth_rich":
	Example 2		Example 2
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"method" : "POST,		"method" : "POST,
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"client": {		"client": {
	"id" : "di3872h34dkJW"		"id" : "di3872h34dkJW"
	},		},
	"interaction": {		"interaction": {
	"indirect": {		"indirect": {
	"information_uri": "https://device.example/c/indirect"		"information_uri": "https://device.example/c/indirect"
	},		},
	"user_code": {		"user_code": {
	"information_uri": "https://device.example/c/user_code"		"information_uri": "https://device.example/c/user_code"
	}		}
	},		},
	"authorization": {		"authorizations": {
	"type" : "oauth_rich",		"play_music": {
	"scope" : "play_music",		"type" : "oauth_scope",
	"authorization_details" [		"scope" : "play_music",
	{		},
	"type": "customer_information",		"read_user_info: {
	"locations": [		"type" : "oauth_rich",
	"https://example.com/customers",		"authorization_details" [
	]		{
	"actions": [		"type": "customer_information",
	"read"		"locations": [
	],		"https://example.com/customers",
	"datatypes": [		]
	"contacts",		"actions": [
	"photos"		"read"
	]		],
	}		"datatypes": [
	]		"contacts",
			"photos"
			]
			}
			]
			}
	}		}
	}		}
	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:
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 25 ¶
	- *oidc* - is an object containing both the "iss" and "sub"		- *oidc* - is an object containing both the "iss" and "sub"
	attributes from an OpenID Connect ID Token [OIDC] Section 2.		attributes from an OpenID Connect ID Token [OIDC] Section 2.
	* *claims* - an optional object containing one or more assertions		* *claims* - an optional object containing one or more assertions
	the Client has about the User.		the Client has about the User.
	- *oidc_id_token* - an OpenID Connect ID Token per [OIDC]		- *oidc_id_token* - an OpenID Connect ID Token per [OIDC]
	Section 2.		Section 2.
	3.5.4. "authorization" Object		3.5.4. "authorizations" Object
			Contains either an authorization request object, or key / 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
			"type" is reserved and MUST not be used by the client. The GS
			detects the authorizations object contains an authorization request
			object by the presence of the "type" property.
			3.5.5. Authorization Request Object
	* *type* - one of the following values: "oauth_scope" or		* *type* - one of the following values: "oauth_scope" or
	"oauth_rich". Extensions MAY define additional types, and the		"oauth_rich". Extensions MAY define additional types, and the
	required attributes. This attribute is REQUIRED.		required attributes. This attribute is REQUIRED.
	* *scope* - a string containing the OAuth 2.0 scope per [RFC6749]		* *scope* - a string containing the OAuth 2.0 scope per [RFC6749]
	section 3.3. MUST be included if type is "oauth_scope". MAY be		section 3.3. MUST be included if type is "oauth_scope". MAY be
	included if type is "oauth_rich".		included if type is "oauth_rich".
	* *authorization_details* - an authorization_details JSON array of		* *authorization_details* - an authorization_details JSON array of
	objects per [RAR]. MUST be included if type is "oauth_rich".		objects per [RAR]. MUST be included if type is "oauth_rich".
	MUST not be included if type is "oauth_scope"		MUST not be included if type is "oauth_scope"
	_[Editor: details may change as the RAR document evolves]_		_[Editor: details may change as the RAR document evolves]_
	3.5.5. "authorizations" Object
	One or more key / value pairs, where each unique key is created by
	the client, and the value is an authorization object per
	Section 3.5.4.
	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
	- *id_token* - Claims that will be included in the returned ID		- *id_token* - Claims that will be included in the returned ID
	skipping to change at page 20, line 38 ¶		skipping to change at page 21, line 4 ¶
	* 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		* authorization or 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
	"authorization": {		"authorizations": {
	"access": {		"access": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_contacts"		"scope" : "read_contacts"
	},		},
	"expires_in" : 3600,		"expires_in" : 3600,
	"mechanism" : "bearer",		"mechanism" : "bearer",
	"token" : "eyJJ2D6.example.access.token.mZf9p"		"token" : "eyJJ2D6.example.access.token.mZf9p"
	},		},
	"claims": {		"claims": {
	"oidc": {		"oidc": {
	skipping to change at page 21, line 36 ¶		skipping to change at page 22, line 5 ¶
	}		}
	}		}
	}		}
	Note in this example the access token can not be refreshed, and		Note in this example the access token can not be refreshed, and
	expires in an hour.		expires in an hour.
	Example non-normative Grant Response JSON document for Example 2 in		Example non-normative Grant Response JSON document for Example 2 in
	Section 3.2:		Section 3.2:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"uri" : "https://as.example/endpoint/grant/example2",		"uri" : "https://as.example/endpoint/grant/example2",
	"authorization": {		"authorizations": {
	"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/"}
	}		}
			}
	Note in this example the GS only provided the AZ URI, and Client must		Note in this example the GS only provided the AZ URIs, and Client
	acquire the Authorization per Section 3.6		must acquire the Authorizations per Section 3.6
	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
	* interaction		* interaction
	and MAY include the following from the Response JSON Section 4.4		and MAY include the following from the Response JSON Section 4.4
	skipping to change at page 22, line 27 ¶		skipping to change at page 22, line 46 ¶
	* warnings		* warnings
	A non-normative example of an Interaction Response follows:		A non-normative example of an Interaction Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example4",		"uri" : "https://as.example/endpoint/grant/example4",
	"interaction" : {		"interaction" : {
	""redirect" : {		"redirect" : {
	"redirect_uri" : "https://as.example/i/example4"		"redirect_uri" : "https://as.example/i/example4"
	}		}
	}		}
	}		}
	4.3. Wait Response		4.3. Wait Response
	The Wait Response MUST include the following from the Response JSON		The Wait Response MUST include the following from the Response JSON
	Section 4.4		Section 4.4
	skipping to change at page 23, line 47 ¶		skipping to change at page 24, line 18 ¶
	return an interaction object containing one or more interaction mode		return an interaction object containing one or more interaction mode
	responses per Section 5 to one or more of the interaction mode		responses per Section 5 to one or more of the interaction mode
	requests provided by the Client.		requests provided by the Client.
	4.4.3. "user" Object		4.4.3. "user" Object
	* *exists* - a boolean value indicating if the GS has a user with		* *exists* - a boolean value indicating if the GS has a user with
	one or more of the provided identifiers in the Request		one or more of the provided identifiers in the Request
	user.identifiers object Section 3.5.3		user.identifiers object Section 3.5.3
	4.4.4. "authorization" Object		4.4.4. "authorizations" Object
	The authorization object MUST contain only a "uri" attribute or the		The authorizations object MUST contain either an authorization
	following from Authorization JSON Section 4.5:		response object Section 4.4.5, or a key / value pair for each key in
			the Grant Request "authorizations" objectSection 3.5.4, and the value
			is an authorization response object Section 4.4.5.
			4.4.5. Authorization response Object
			The authorization response object MUST contain only a "uri" attribute
			or the following from Authorization JSON Section 4.5:
	* mechanism		* mechanism
	* token		* token
	The authorization object MAY contain any of the following from		The authorization object MAY contain any of the following from
	Authorization JSON Section 4.5:		Authorization JSON Section 4.5:
	* access		* access
	* expires_in		* expires_in
	* uri		* uri
	If there is no "uri" attribute, the access token can not be		If there is no "uri" attribute, the access token can not be
	refreshed. If only the "uri" attribute is present, the Client MUST		refreshed. If only the "uri" attribute is present, the Client MUST
	acquire the Authorization per Section 3.6		acquire the Authorization per Section 3.6
	4.4.5. "authorizations" Object
	A key / value pair for each key in the Grant Request "authorizations"
	object, and the value is per Section 4.4.4.
	4.4.6. "claims" Object		4.4.6. "claims" Object
	The claims object is a response to the Grant Request "claims" object		The claims object is a response to the Grant Request "claims" object
	Section 3.5.4.		Section 3.5.6.
	* *oidc*		* *oidc*
	- *id_token* - an OpenID Connect ID Token containing the Claims		- *id_token* - an OpenID Connect ID Token containing the Claims
	the User consented to be released.		the User consented to be released.
	- *userinfo* - the Claims the User consented to be released.		- *userinfo* - the Claims the User consented to be released.
	Claims are defined in [OIDC] Section 5.		Claims are defined in [OIDC] Section 5.
	* *oidc4ia* - OpenID Connect for Identity Assurance claims response		* *oidc4ia* - OpenID Connect for Identity Assurance claims response
	per [OIDC4IA].		per [OIDC4IA].
	skipping to change at page 25, line 7 ¶		skipping to change at page 25, line 25 ¶
	The verified claims the user consented to be released. _[Editor:		The verified claims the user consented to be released. _[Editor:
	details TBD]_		details TBD]_
	4.4.7. "warnings" JSON Array		4.4.7. "warnings" JSON Array
	Includes zero or more warnings from Section 8,		Includes zero or more warnings from Section 8,
	4.5. Authorization JSON		4.5. Authorization JSON
	The Authorization JSON is the contents of a Grant Response		The Authorization JSON is a Grant Response Authorization Object
	"authorization" object Section 4.4.5 or the response to a Read AuthZ		Section 4.4.5 or the response to a Read AuthZ request by the Client
	request by the Client Section 3.6.		Section 3.6.
	* *type* - the type of claim request: "oauth_scope" or "oauth_rich".
	See the "type" object in Section 3.5.4 for details.
	* *mechanism* - the RS access mechanism. This document defines the		* *mechanism* - the RS access mechanism. This document defines the
	"bearer" mechanism as defined in Section 6		"bearer" mechanism as defined in Section 6
	* *token* - the access token for accessing an RS.		* *token* - the access token for accessing an RS.
	* *expires_in* - a numeric value specifying how many seconds until		* *expires_in* - a numeric value specifying how many seconds until
	the access token expires.		the access token expires.
	* *uri* - the AZ URI. Used to acquire or refresh an authorization.		* *uri* - the AZ URI. Used to acquire or refresh an authorization.
	skipping to change at page 28, line 11 ¶		skipping to change at page 28, line 27 ¶
	* *code* the code the Client displays to the User to enter at the		* *code* the code the Client displays to the User to enter at the
	display_uri. This attribute is REQUIRED.		display_uri. This attribute is REQUIRED.
	* *display_uri* the URI the Client displays to the User to load in a		* *display_uri* the URI the Client displays to the User to load in a
	browser to enter the code.		browser to enter the code.
	6. RS Access		6. RS Access
	The mechanism the Client MUST use to access an RS is in the		The mechanism the Client MUST use to access an RS is in the
	Authorization JSON "mechanism" attribute Section 4.4.4.		Authorization JSON "mechanism" attribute Section 4.4.5.
	The "bearer" mechanism is defined in Section 2.1 of [RFC6750]		The "bearer" mechanism is defined in Section 2.1 of [RFC6750]
	The "jose" and "jose+body" mechanisms are defined in		The "jose" and "jose+body" mechanisms are defined in
	[JOSE_Authentication]		[JOSE_Authentication]
	A non-normative "bearer" example of the HTTP request headers follows:		A non-normative "bearer" example of the HTTP request headers follows:
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	skipping to change at page 37, line 4 ¶		skipping to change at page 37, line 21 ¶
	A.12. draft-hardt-xauth-protocol-11		A.12. draft-hardt-xauth-protocol-11
	* renamed authorization_uri to interaction_uri to avoid confusion		* renamed authorization_uri to interaction_uri to avoid confusion
	with AZ URI		with AZ URI
	* made URI names more consistent		* made URI names more consistent
	- renamed completion_uri to information_uri		- renamed completion_uri to information_uri
	- renamed redirect_uri to completion_uri		- renamed redirect_uri to completion_uri
	- renamed interaction_uri to redirect_uri		- renamed interaction_uri to redirect_uri
	- renamed short_uri to indirect_uri		- renamed short_uri to indirect_uri
	* editorial fixes		* editorial fixes
	* 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
			* removed authorization object, and made authorizations object
			polymorphic
	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
End of changes. 37 change blocks.
	84 lines changed or deleted		100 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/