< draft-hardt-xauth-protocol-06.txt		draft-hardt-xauth-protocol-07.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 22 March 2020		Intended status: Standards Track 6 June 2020
	Expires: 23 September 2020		Expires: 8 December 2020
	The XAuth Protocol		The Grant Negotiation and Authorization Protocol
	draft-hardt-xauth-protocol-06		draft-hardt-xauth-protocol-07
	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
	the authorization and identity claims that were approved. This		the authorization and identity claims that were approved. This
	protocol can be extended to support alternative authorizations,		protocol can be extended to support alternative authorizations,
	claims, interactions, and client authentication mechanisms.		claims, interactions, and client authentication mechanisms.
	Note to Readers
	Source for this draft and an issue tracker can be found at
	https://github.com/dickhardt/hardt-xauth-protocol
	(https://github.com/dickhardt/hardt-xauth-protocol).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 23 September 2020.		This Internet-Draft will expire on 8 December 2020.
	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 28 ¶		skipping to change at page 2, line 18 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.4. Notational Conventions . . . . . . . . . . . . . . . . . 7		1.4. Notational Conventions . . . . . . . . . . . . . . . . . 7
	2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Create and Verify Grant . . . . . . . . . . . . . . . . . 8		2.1. Create and Verify Grant . . . . . . . . . . . . . . . . . 8
	2.2. Create and Read Grant - Redirect . . . . . . . . . . . . 10		2.2. Create and Read Grant - Redirect . . . . . . . . . . . . 9
	2.3. Create and Read Grant - Indirect . . . . . . . . . . . . 11		2.3. Create and Read Grant - Indirect . . . . . . . . . . . . 10
	2.4. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 11		2.4. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 11
	2.5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 12		2.5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 12
	2.6. Create and Update . . . . . . . . . . . . . . . . . . . . 13		2.6. Create and Update . . . . . . . . . . . . . . . . . . . . 12
	2.7. Create and Delete . . . . . . . . . . . . . . . . . . . . 15		2.7. Create and Delete . . . . . . . . . . . . . . . . . . . . 14
	2.8. Create, Discover, and Delete . . . . . . . . . . . . . . 17		2.8. Create, Discover, and Delete . . . . . . . . . . . . . . 16
	2.9. Create and Wait . . . . . . . . . . . . . . . . . . . . . 17		2.9. Create and Wait . . . . . . . . . . . . . . . . . . . . . 16
	2.10. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 18		2.10. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 17
	2.11. Resource Server Access . . . . . . . . . . . . . . . . . 19		2.11. Resource Server Access . . . . . . . . . . . . . . . . . 18
	2.12. GS API Table . . . . . . . . . . . . . . . . . . . . . . 20		2.12. GS API Table . . . . . . . . . . . . . . . . . . . . . . 19
	3. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 20		3. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 19
	4. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		4. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 21		4.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 20
	4.2. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 24		4.2. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 23
	4.3. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 24		4.3. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 24
	4.4. Update Grant . . . . . . . . . . . . . . . . . . . . . . 25		4.4. Update Grant . . . . . . . . . . . . . . . . . . . . . . 24
	4.5. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 26		4.5. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 25
	4.6. Request JSON . . . . . . . . . . . . . . . . . . . . . . 26		4.6. Request JSON . . . . . . . . . . . . . . . . . . . . . . 25
	4.6.1. "client" Object . . . . . . . . . . . . . . . . . . . 26		4.6.1. "client" Object . . . . . . . . . . . . . . . . . . . 25
	4.6.2. "interaction" Object . . . . . . . . . . . . . . . . 27		4.6.2. "interaction" Object . . . . . . . . . . . . . . . . 26
	4.6.3. "user" Object . . . . . . . . . . . . . . . . . . . . 28		4.6.3. "user" Object . . . . . . . . . . . . . . . . . . . . 26
	4.6.4. "authorization" Object . . . . . . . . . . . . . . . 28		4.6.4. "authorization" Object . . . . . . . . . . . . . . . 27
	4.6.5. "authorizations" Object . . . . . . . . . . . . . . . 28		4.6.5. "authorizations" Object . . . . . . . . . . . . . . . 27
	4.6.6. "claims" Object . . . . . . . . . . . . . . . . . . . 29		4.6.6. "claims" Object . . . . . . . . . . . . . . . . . . . 27
	4.6.7. "verification" Object . . . . . . . . . . . . . . . . 29		4.6.7. "verification" Object . . . . . . . . . . . . . . . . 28
	4.7. Read Authorization . . . . . . . . . . . . . . . . . . . 29		4.7. Read Authorization . . . . . . . . . . . . . . . . . . . 28
	4.8. Update Authorization . . . . . . . . . . . . . . . . . . 30		4.8. Update Authorization . . . . . . . . . . . . . . . . . . 28
	4.9. Delete Authorization . . . . . . . . . . . . . . . . . . 30		4.9. Delete Authorization . . . . . . . . . . . . . . . . . . 29
	4.10. GS Options . . . . . . . . . . . . . . . . . . . . . . . 30		4.10. GS Options . . . . . . . . . . . . . . . . . . . . . . . 29
	4.11. Grant Options . . . . . . . . . . . . . . . . . . . . . . 31		4.11. Grant Options . . . . . . . . . . . . . . . . . . . . . . 30
	4.12. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 32		4.12. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 30
	4.13. Request Verification . . . . . . . . . . . . . . . . . . 32		4.13. Request Verification . . . . . . . . . . . . . . . . . . 30
	5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 32		5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 31
	6. GS API Responses . . . . . . . . . . . . . . . . . . . . . . 32		6. GS Responses . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 32		6.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 31
	6.2. Interaction Response . . . . . . . . . . . . . . . . . . 34		6.2. Interaction Response . . . . . . . . . . . . . . . . . . 32
	6.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 34		6.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 33
	6.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 35		6.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 34
	6.4.1. "interaction" Object . . . . . . . . . . . . . . . . 35		6.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 34
	6.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 36		6.4.2. "interaction" Object . . . . . . . . . . . . . . . . 34
	6.4.3. "authorization" Object . . . . . . . . . . . . . . . 36		6.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 34
	6.4.4. "authorizations" Object . . . . . . . . . . . . . . . 36		6.4.4. "authorization" Object . . . . . . . . . . . . . . . 34
	6.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 36		6.4.5. "authorizations" Object . . . . . . . . . . . . . . . 34
	6.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 37		6.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 35
	6.5.1. Signing and Encryption . . . . . . . . . . . . . . . 38		6.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 35
	6.6. Response Verification . . . . . . . . . . . . . . . . . . 38		6.5.1. Signing and Encryption . . . . . . . . . . . . . . . 36
	7. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 38		6.6. Response Verification . . . . . . . . . . . . . . . . . . 36
	7.1. Redirect Interaction . . . . . . . . . . . . . . . . . . 38		7. interaction mode Objects . . . . . . . . . . . . . . . . . . 36
	7.2. Indirect Interaction . . . . . . . . . . . . . . . . . . 40		7.1. "redirect" mode . . . . . . . . . . . . . . . . . . . . . 37
	8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 40		7.1.1. request "interaction" object contains: . . . . . . . 37
	8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 41		7.1.2. response "interaction" object contains: . . . . . . . 37
	9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 41		7.2. "indirect" mode . . . . . . . . . . . . . . . . . . . . . 37
	10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 41		7.2.1. request "interaction" object contains: . . . . . . . 37
	10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 42		7.2.2. response "interaction" object contains: . . . . . . . 37
	10.1.1. Authorization Header . . . . . . . . . . . . . . . . 42		7.3. "user_code" mode . . . . . . . . . . . . . . . . . . . . 37
	10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 43		7.3.1. request "interaction" object contains: . . . . . . . 38
	10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 44		7.3.2. response "interaction" object contains: . . . . . . . 38
	10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 45		8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 45		8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 38
	10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 45		9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 38
	10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 46		10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 38
	10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 47		10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 39
	10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 48		10.1.1. Authorization Header . . . . . . . . . . . . . . . . 40
	10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 48		10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 41
	10.5. Response Encryption . . . . . . . . . . . . . . . . . . 48		10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 42
	11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 48		10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 42
	12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 49		10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 43
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53		10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 43
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53		10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 44
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 53		10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 45
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 53		10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 45
	16.1. Normative References . . . . . . . . . . . . . . . . . . 53		10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 45
	16.2. Informative References . . . . . . . . . . . . . . . . . 55		10.5. Response Encryption . . . . . . . . . . . . . . . . . . 46
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 56		11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 56		12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 56		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 57		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 57		15. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 57		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
	A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 57		16.1. Normative References . . . . . . . . . . . . . . . . . . 51
	A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 57		16.2. Informative References . . . . . . . . . . . . . . . . . 53
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 58
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59		Appendix A. Document History . . . . . . . . . . . . . . . . . . 54
			A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 54
			A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 54
			A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 55
			A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 55
			A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 55
			A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 55
			A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 55
			A.8. draft-hardt-xauth-protocol-07 . . . . . . . . . . . . . . 56
			Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 56
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	This protocol supports the widely deployed use cases supported by		This protocol supports the widely deployed use cases supported by
	OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an		OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an
	extension of OAuth 2.0, as well as other extensions, and other use		extension of OAuth 2.0, as well as other extensions, and other use
	cases that are not supported, such as acquiring multiple access		cases that are not supported, such as acquiring multiple access
	tokens at the same time, and updating the request during user		tokens at the same time, and updating the request during user
	interaction. This protocol also addresses many of the security		interaction. This protocol also addresses many of the security
	issues in OAuth 2.0 by having parameters securely sent directly		issues in OAuth 2.0 by having parameters securely sent directly
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	MUST start with the GS URI.		MUST start with the GS URI.
	* *Authorization* - the access granted by the RO to the Client.		* *Authorization* - the access granted by the RO to the Client.
	Contains an access token.		Contains an access token.
	* *Authorization URI* (AZ URI) - the URI that represents the		* *Authorization URI* (AZ URI) - the URI that represents the
	Authorization the Client was granted by the RO. The AZ URI MUST		Authorization the Client was granted by the RO. The AZ URI MUST
	start with the GS URI. The AZ URI is used to read, update, and		start with the GS URI. The AZ URI is used to read, update, and
	delete an access token.		delete an access token.
	* *Redirect Interaction* - characterized by the GS returning the		* *Interaction* - how the Client directs the User to interact with
	User back to the Client that started the interaction.		the GS. This document defines the interaction modes redirect,
			indirect, and user_code in Section 7
	* *Indirect Interaction* - characterized by the GS not being able to
	return the User back to the Client that started the interaction.
	* *Redirect URI* - a URI at the GS that the Client will redirect the
	User to in a Redirect Interaction. This URI is unique is unique
	to an outstanding Create Grant request.
	* *Completion URI* - the URI at the Client that the GS will redirect
	the User back to in a Redirect Interaction. If the Client has not
	set the interaction.verify flag, this URI is unique to the Create
	Grant request made by the Client.
	* *Information URI* - the URI the GS will redirect the User to after
	an Indirect Interaction.
	* *Short URI* - a URI at the GS that is used in Indirect
	Interactions. The URI may be presented to the User as a scannable
	code, or loaded in a system browser by the Client. The URI has a
	maximum length of TBD bytes, and is unique to an outstanding
	Create Grant request.
	* *Code URI* - a URI at the GS presented to the User by the Client
	for the User to enter the User Code in an Indirect Interaction.
	* *User Code* - a string generated by the GS that is is unique to an		* *Client Handle* - a GS unique identifier for a Dynamic Client for
	outstanding Create Grant request in an Indirect Interaction.		the Dynamic Client to refer to itself in subsequent requests.
	1.4. Notational Conventions		1.4. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	specification are to be interpreted as described in [RFC2119].		specification are to be interpreted as described in [RFC2119].
	Certain security-related terms are to be understood in the sense		Certain security-related terms are to be understood in the sense
	defined in [RFC4949]. These terms include, but are not limited to,		defined in [RFC4949]. These terms include, but are not limited to,
	"attack", "authentication", "authorization", "certificate",		"attack", "authentication", "authorization", "certificate",
	skipping to change at page 19, line 37 ¶		skipping to change at page 18, line 37 ¶
	| | | | | |		| | | | | |
	| | +----------+ | |		| | +----------+ | |
	| | | |		| | | |
	| |--(4)--- Read AuthZ ---------------------->| |		| |--(4)--- Read AuthZ ---------------------->| |
	| |<------- AuthZ Response -------------------| |		| |<------- AuthZ Response -------------------| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Read AuthZ* The Client makes a Read AuthZ (Section 4.7) with an		1. *Read AuthZ* The Client makes a Read AuthZ (Section 4.7) with an
	HTTP GET to the AZ URI and receives an Response JSON		HTTP GET to the AZ URI and receives an Response JSON
	"authorization" object (Section 6.4.3) with a fresh access token.		"authorization" object (Section 6.4.4) with a fresh access token.
	2. *Resource Request* The Client accesses the RS with the access		2. *Resource Request* The Client accesses the RS with the access
	token per Section 8 and receives a response from the RS.		token per Section 8 and receives a response from the RS.
	3. *Resource Request* The Client attempts to access the RS, but		3. *Resource Request* The Client attempts to access the RS, but
	receives an error indicating the access token has expired.		receives an error indicating the access token has expired.
	4. *Read AuthZ* The Client makes another Read AuthZ (Section 4.7)		4. *Read AuthZ* The Client makes another Read AuthZ (Section 4.7)
	with an HTTP GET to the AZ URI and receives an Response JSON		with an HTTP GET to the AZ URI and receives an Response JSON
	"authorization" object (Section 6.4.3) with a fresh access token.		"authorization" object (Section 6.4.4) with a fresh access token.
	2.12. GS API Table		2.12. GS API Table
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| request | http verb | uri | response |		| request | http verb | uri | response |
	+==============+===========+========+=============================+		+==============+===========+========+=============================+
	| Create Grant | POST | GS URI | interaction, wait, or grant |		| Create Grant | POST | GS URI | interaction, wait, or grant |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Verify Grant | PATCH | Grant | grant |		| Verify Grant | PATCH | Grant | grant |
	| | | URI | |		| | | URI | |
	skipping to change at page 21, line 16 ¶		skipping to change at page 20, line 16 ¶
	created for the same GS, Client, and User tuple.		created for the same GS, Client, and User tuple.
	At any point in time, there can only be one Grant for the GS, Client,		At any point in time, there can only be one Grant for the GS, Client,
	and User tuple. When a Client creates a Grant at the same GS for the		and User tuple. When a Client creates a Grant at the same GS for the
	same User, the GS MUST invalidate a previous Grant for the Client at		same User, the GS MUST invalidate a previous Grant for the Client at
	that GS for that User.		that GS for that User.
	*Authorization Life Cycle*		*Authorization Life Cycle*
	An Authorization are represented by an AZ URI and are MAY be included		An Authorization are represented by an AZ URI and are MAY be included
	in a Grant Response "authorization" Object (Section 6.4.3) or as a		in a Grant Response "authorization" Object (Section 6.4.4) or as a
	member of the Grant Response "authorizations" list. If a Client		member of the Grant Response "authorizations" list. If a Client
	receives an Authorization, the Client MUST be able to do a Read AuthZ		receives an Authorization, the Client MUST be able to do a Read AuthZ
	request Section 4.7, and MAY be able to update Section 4.8 and delete		request Section 4.7, and MAY be able to update Section 4.8 and delete
	Section 4.9 depending on GS policy.		Section 4.9 depending on GS policy.
	An Authorization will persist independent of the Grant, and persist		An Authorization will persist independent of the Grant, and persist
	until invalidated by the GS per GS policy, or deleted by the Client.		until invalidated by the GS per GS policy, or deleted by the Client.
	4. GS APIs		4. GS APIs
	skipping to change at page 22, line 20 ¶		skipping to change at page 21, line 20 ¶
	* claims		* claims
	The GS MUST respond with one of Grant Response Section 6.1,		The GS MUST respond with one of Grant Response Section 6.1,
	Interaction Response Section 6.2, Wait Response Section 6.3, or one		Interaction Response Section 6.2, Wait Response Section 6.3, or one
	of the following errors:		of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	Following is a non-normative example where the Client wants is		Following is a non-normative example where the Client is requesting
	requesting identity claims about the User and read access to the		identity claims about the User and read access to the User's
	User's contacts:		contacts:
	Example 1		Example 1
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"client": {		"client": {
	"display": {		"display": {
	"name" : "SPA Display Name",		"name" : "SPA Display Name",
	"uri" : "https://spa.example/about"		"uri" : "https://spa.example/about"
	}		}
	},		},
	"interaction": {		"interaction": {
	"type" : "redirect",		"redirect": {
	"completion_uri" : "https://web.example/return"		"redirect_uri" : "https://web.example/return"
			},
			"global" : {
			"ui_locals" : "de"
			}
	},		},
	"authorization": {		"authorization": {
	"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 }
	skipping to change at page 24, line 15 ¶		skipping to change at page 23, line 15 ¶
	Example 2		Example 2
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"client": {		"client": {
	"id" : "di3872h34dkJW"		"id" : "di3872h34dkJW"
	},		},
	"interaction": {		"interaction": {
	"keep" : true,		"indirect": {
	"type" : "redirect",		"completion_uri": "https://device.example/completion"
	"completion_uri" : "https://web.example/return"		},
			"user_code": {
			"completion_uri": "https://device.example/completion"
			}
	},		},
	"user": {		"user": {
	"identifiers": {		"identifiers": {
	"email" : "jane.doe@example.com"		"email" : "jane.doe@example.com"
	},		},
	"exists" : true		"exists" : true
	},		},
	"claims" : { "oidc": { "id_token" : {} } }		"claims" : { "oidc": { "id_token" : {} } }
	}		}
	skipping to change at page 26, line 46 ¶		skipping to change at page 25, line 46 ¶
	* *iat* - the time of the request as a NumericDate.		* *iat* - the time of the request as a NumericDate.
	* *nonce* - a unique identifier for this request. Note the Grant		* *nonce* - a unique identifier for this request. Note the Grant
	Response MUST contain a matching nonce attribute value.		Response MUST contain a matching nonce attribute value.
	* *uri* - the GS URI if in a Create Grant Section 4.1, or the Grant		* *uri* - the GS URI if in a Create Grant Section 4.1, or the Grant
	URI if in an Update Grant Section 4.4.		URI if in an Update Grant Section 4.4.
	4.6.1. "client" Object		4.6.1. "client" Object
	The client object MUST contain either the id attribute for Registered		The client object MUST contain one of: the "id" attribute for a
	Clients, or the display object for Dynamic Clients.		Registered Client, the "handle" attribute for a Dynamic Client, or
			the "display" object for Dynamic Clients.
	* *id* - the Client ID the GS has for the Registered Client.		* *id* - the Client ID the GS has for a Registered Client.
			* *handle* = the Client Handle the GS previously provided a Dynamic
			Client
	* *display* - the display object contains the following attributes:		* *display* - the display object contains the following attributes:
	- *name* - a string that represents the Dynamic Client		- *name* - a string that represents the Dynamic Client
	- *uri* - a URI representing the Dynamic Client		- *uri* - a URI representing the Dynamic Client
	The name and uri will be displayed by the GS when prompting for		The name and uri will be displayed by the GS when prompting for
	authorization.		authorization.
	[Editor: a max length for the name and URI so a GS can reserve		[Editor: a max length for the name and URI so a GS can reserve
	appropriate space?]		appropriate space?]
	4.6.2. "interaction" Object		4.6.2. "interaction" Object
	The interaction object contains the type of interaction the Client		The interaction object contains one or more interaction mode objects
	will provide the User. Other attributes		per Section 7 representing the interactions the Client is willing to
			provide the User. In addition to the interaction mode objects, the
	* *keep* - a JSON boolean. If set to the JSON value true, the GS		interaction object may contain the "global" object;
	will not transfer the User interaction back to the Client after
	processing the Grant request. The JSON value false is equivalent
	to the attribute not being present, and the GS will transfer the
	User interaction back to the Client after processing the request.
	This attribute is OPTIONAL
	* *type* - contains one of the following values: "redirect" or
	"indirect". Details in Section 7. This attribute is REQUIRED.
	[Editor: do we want this to be an array of types the Client can
	support? This would only be the case if the GS is not able to
	support all types and negotiation is required. Is that required?]
	* *completion_uri* - this attribute is REQUIRED if the type is
	"redirect". It is the URI that the Client requests the GS to
	redirect the User to after the GS has completed interacting with
	the User. If the Client manages session state in URIs, then the
	redirect_uri SHOULD contain that state.
	* *information_uri* - this attribute is OPTIONAL and is ignored		* *global* - and optional object containing parameters that are
	unless the type is "indirect". This is the URI the Client would		applicable for all types of interactions. Only one attribute is
	like the GS to redirect the User to after the interaction with the		defined in this document:
	User is complete.
	* *ui_locales* - End-User's preferred languages and scripts for the		- *ui_locales* - End-User's preferred languages and scripts for
	user interface, represented as a space-separated list of [RFC5646]		the user interface, represented as a space-separated list of
	language tag values, ordered by preference. This attribute is		[RFC5646] language tag values, ordered by preference. This
	OPTIONAL.		attribute is OPTIONAL.
	* *verify* - a boolean value. If set to the JSON value true, the GS		[Editor: why is this not a JSON array? Why space-separated?]
	will return a nonce value with the Completion URI.
	4.6.3. "user" Object		4.6.3. "user" Object
	* *exists* - if present, MUST contain the JSON true value.		* *exists* - if present, MUST contain the JSON true value.
	Indicates the Client requests the GS to return a user.exists value		Indicates the Client requests the GS to return a user.exists value
	in an Interaction Response Section 6.2. This attribute is		in an Interaction Response Section 6.2. This attribute is
	OPTIONAL, and MAY be ignored by the GS.		OPTIONAL, and MAY be ignored by the GS.
	* *identifiers* - REQUIRED if the exists attribute is present. The		* *identifiers* - REQUIRED if the exists attribute is present. The
	values MAY be used by the GS to improve the User experience.		values MAY be used by the GS to improve the User experience.
	skipping to change at page 28, line 50 ¶		skipping to change at page 27, line 34 ¶
	section 3.3. MUST be included if type is "oauth_scope" or		section 3.3. MUST be included if type is "oauth_scope" or
	"oauth_rich".		"oauth_rich".
	* *authorization_details* - an authorization_details object per		* *authorization_details* - an authorization_details object per
	[RAR]. MUST be included if type is "oauth_rich".		[RAR]. MUST be included if type is "oauth_rich".
	[Editor: details may change as the [RAR] document evolves]		[Editor: details may change as the [RAR] document evolves]
	4.6.5. "authorizations" Object		4.6.5. "authorizations" Object
	A JSON array of "authorization" objects. Only one of "authorization"		One or more key / value pairs, where each unique key is created by
	or "authorizations" may be in the Request JSON.		the client, and the value is an authorization object.
	[Editor: instead of an array, we could have a Client defined
	dictionary of "authorization" objects]
	4.6.6. "claims" Object		4.6.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 30, line 51 ¶		skipping to change at page 29, line 31 ¶
	The GS MUST respond with the the following JSON document:		The GS MUST respond with the the following JSON document:
	[Editor: this section is a work in progress]		[Editor: this section is a work in progress]
	* *uri* - the GS URI.		* *uri* - the GS URI.
	* *client_authentication* - an array of the Client Authentication		* *client_authentication* - an array of the Client Authentication
	mechanisms supported by the GS		mechanisms supported by the GS
	* *interactions* - an array of the interaction types supported by		* *interactions* - an array of the interaction modes supported by
	the GS.		the GS.
	* *authorization* - an object containing the authorizations the		* *authorization* - an object containing the authorizations the
	Client may request from the GS, if any.		Client may request from the GS, if any.
	- Details TBD		- Details TBD
	* *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 list of the cryptographic algorithms supported by		* *algorithms* - a list of the cryptographic algorithms supported by
	the GS.		the GS.
	* *features* - an object containing feature support		* *features* - an object containing feature support
	- *user_exists* - boolean indicating if user.exists is supported.		- *user_exists* - boolean indicating if user.exists is supported.
	- *authorizations* - boolean indicating if a request for multiple		- *authorizations* - boolean indicating if a request for more
	authorizations is supported.		than one authorization in a request is supported.
	[Editor: keys used by Client to encrypt requests, or verify signed		[Editor: keys used by Client to encrypt requests, or verify signed
	responses?]		responses?]
	[Editor: namespace metadata for extensions?]		[Editor: namespace metadata for extensions?]
	or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	skipping to change at page 32, line 45 ¶		skipping to change at page 31, line 26 ¶
	*initiation_uri* A URI at the Client that contains no query or		*initiation_uri* A URI at the Client that contains no query or
	fragment. How the GS learns the Client initiation_uri is out of		fragment. How the GS learns the Client initiation_uri is out of
	scope.		scope.
	The GS creates a Grant and Grant URI, and redirects the User to the		The GS creates a Grant and Grant URI, and redirects the User to the
	initiation_uri with the query parameter "grant" and the value of		initiation_uri with the query parameter "grant" and the value of
	Grant URI.		Grant URI.
	See Section 2.5 for the sequence diagram.		See Section 2.5 for the sequence diagram.
	6. GS API Responses		6. GS Responses
			There are three successful responses to a grant request: Grant
			Response, Interaction Response, or Wait Response.
	6.1. Grant Response		6.1. Grant Response
	The Grant Response MUST include the following from the Response JSON		The Grant Response MUST include the following from the Response JSON
	Section 6.4		Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	and MAY include the following from the Response JSON Section 6.4		and MAY include the following from the Response JSON Section 6.4
			* client.handle
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	* expires_in		* expires_in
	Example non-normative Grant Response JSON document for Example 1 in		Example non-normative Grant Response JSON document for Example 1 in
	Section 4.1:		Section 4.1:
	{		{
	"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": {		"authorization": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	skipping to change at page 34, line 24 ¶		skipping to change at page 33, line 4 ¶
	6.2. Interaction Response		6.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 6.4		JSON Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* interaction		* interaction
	and MAY include the following from the Response JSON Section 6.4		and MAY include the following from the Response JSON Section 6.4
	* user		* user
	* wait		* wait
	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" : {
	"type" : "redirect",		""redirect" : {
	"redirect_uri" : "https://as.example/i/example4"		"authorization_uri" : "https://as.example/i/example4"
			}
	},		},
	"user": {		"user": {
	"exists" : true		"exists" : true
	}		}
	}		}
	6.3. Wait Response		6.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 6.4		Section 6.4
	skipping to change at page 35, line 39 ¶		skipping to change at page 34, line 23 ¶
	* *uri* - the Grant URI.		* *uri* - the Grant URI.
	* *wait* - a numeric value representing the number of seconds the		* *wait* - a numeric value representing the number of seconds the
	Client should want before making a Read Grant request to the Grant		Client should want before making a Read Grant request to the Grant
	URI.		URI.
	* *expires_in* - a numeric value specifying how many seconds until		* *expires_in* - a numeric value specifying how many seconds until
	the Grant expires. This attribute is OPTIONAL.		the Grant expires. This attribute is OPTIONAL.
	6.4.1. "interaction" Object		6.4.1. "client" Object
	If the GS wants the Client to start the interaction, the GS MUST
	return the interaction mechanism provided by the Client in the Grant
	Request, and include the required attributes in the interaction
	object:
	* *type* - this MUST match the type provided by the Client in the
	Grant Request client.interaction object.
	* *authorization_uri* - the URI to redirect the user to or load in
	the popup. Must be included if type is "redirect"
	* *display_uri* - the URI to be displayed to the User for them to
	navigate to and enter the code. Must be included if type is
	"indirect"
	* *user_code* - a text string of the code to display to the User.
	Must be included if type is "indirect".
	* *short_uri* - the URI to show as scannable code. MUST be included
	if type is "indirect"
	[Editor: do we specify a maximum length for the display_uri and code
	so that a device knows the maximum it needs to support? A smart
	device may have limited screen real estate.]
	The authorization_uri, qr_uri, and user_code MUST be unique and only		The GS may
	match the associated Grant URI.
	TBD: entropy and other security considerations for the		6.4.2. "interaction" Object
	authorization_uri, qr_uri, and the user_code.
	See Interaction Types Section 7 for details.		If the GS wants the Client to start the interaction, the GS MUST
			return an interaction object containing one or more interaction mode
			responses per Section 7 to one or more of the interaction mode
			requests provided by the Client.
	6.4.2. "user" Object		6.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 4.6.3		user.identifiers object Section 4.6.3
	6.4.3. "authorization" Object		6.4.4. "authorization" Object
	The Response JSON authorization object is a subset of the		The authorization object contains Authorization JSON Section 6.5.
	Authorization JSON Section 6.5. It contains only the AZ URI if the		See Grant Response Section 6.1 for non-normative examples.
	Client is able to read, update and/or delete the Authorization.
	Alternatively, it contains the Authorization JSON excluding the AZ
	URI. See Grant Response Section 6.1 for non-normative examples.
	6.4.4. "authorizations" Object		6.4.5. "authorizations" Object
	A JSON array of authorization objects. Support for the		A key / value pair for each key in the client's request
	authorizations object is OPTIONAL.		authorizations object, and the value is Authorization JSON
			Section 6.5.
	6.4.5. "claims" Object		6.4.6. "claims" Object
	The claims object is a response to the Request "claims" object		The claims object is a response to the Request "claims" object
	Section 4.6.4.		Section 4.6.4.
	* *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].
	* *vc*		* *vc*
	The verified claims the user consented to be released. [Editor:		The verified claims the user consented to be released. [Editor:
	details TBD]		details TBD]
	6.5. Authorization JSON		6.5. Authorization JSON
	The Authorization JSON is a response to a Read AuthZ request by the		The Authorization JSON is a response to a Read AuthZ request by the
	Client Section 4.7. A subset of the Authorization JSON is included		Client Section 4.7. A subset of the Authorization JSON is included
	in the "authorization" object Section 4.6.4 and "authorizations" list		in the "authorization" object Section 4.6.4 and "authorizations" list
	members Section 6.4.4.		members Section 6.4.5.
	* *type* - the type of claim request: "oauth_scope" or "oauth_rich".		* *type* - the type of claim request: "oauth_scope" or "oauth_rich".
	See the "type" object in Section 4.6.4 for details.		See the "type" object in Section 4.6.4 for details. This
			attribute is REQUIRED.
	* *scope* - the scopes the Client was granted authorization for.		* *scope* - the scopes the Client was granted authorization for.
	This will be all, or a subset, of what was requested. This		This will be all, or a subset, of what was requested. This
	attribute is OPTIONAL.		attribute is OPTIONAL.
	* *authorization_details* - the authorization details granted per		* *authorization_details* - the authorization details granted per
	[RAR]. Included if type is "oauth_rich".		[RAR]. Included if type is "oauth_rich".
	* *mechanism* - one of the access mechanisms: "bearer", "jose", or		* *mechanism* - one of the access mechanisms: "bearer", "jose", or
	"jose+body". See Section 8 for details.		"jose+body". See Section 8 for details. This attribute is
			REQUIRED.
	* *token* - the access token for accessing an RS. This attribute is		* *token* - the access token for accessing an RS. This attribute is
	REQUIRED.		REQUIRED.
	* *expires_in* - a numeric value specifying how many seconds until		* *expires_in* - a numeric value specifying how many seconds until
	the access token expires. This attribute is OPTIONAL.		the access token expires. This attribute is OPTIONAL.
	* *certificate* - MUST be included if the mechanism is "jose" or		* *certificate* - MUST be included if the mechanism is "jose" or
	"jose+body". Contains the jwk header values for the Client to		"jose+body". Contains the jwk header values for the Client to
	include in the JWS header when calling the RS using the "jose" or		include in the JWS header when calling the RS using the "jose" or
	"jose+body" mechanisms. See Section 10.2.1.		"jose+body" mechanisms. See Section 10.2.1.
	* *uri* - the AZ URI. Used to get, update, and delete the		* *uri* - the AZ URI. Used to refresh an authorization. This
	authorization. This will be the same URI that was used in a Read		attribute is OPTIONAL.
	Authorization or Update Authorization request. This attribute is
	REQUIRED unless it is in a Response JSON,
	[Editor: any value in an expiry for the Authorization?]		[Editor: would an optional expiry for the Authorization be useful?]
	The following is a non-normative example of an Authorization JSON		The following is a non-normative example of an Authorization JSON
	document:		document:
	{		{
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_calendar write_calendar",		"scope" : "read_calendar write_calendar",
	"mechanism" : "jose",		"mechanism" : "jose",
	"token" : "eyJJ2D6.example.access.token.mZf9p"		"token" : "eyJJ2D6.example.access.token.mZf9p"
	"expires_in" : 3600,		"expires_in" : 3600,
	skipping to change at page 38, line 35 ¶		skipping to change at page 36, line 44 ¶
	[Editor: TBD - how response is signed and/or encrypted by the GS. Is		[Editor: TBD - how response is signed and/or encrypted by the GS. Is
	there a generalized description, or is it mechanism specific?]		there a generalized description, or is it mechanism specific?]
	6.6. Response Verification		6.6. Response Verification
	On receipt of a response, the Client MUST verify the following:		On receipt of a response, the Client MUST verify the following:
	* TBD		* TBD
	7. Interactions		7. interaction mode Objects
	There are two types of interactions that a Client can initiate with a
	GS: redirect and indirect. Extensions may define additional
	interaction types.
	7.1. Redirect Interaction
	A Redirect Interaction is characterized by the GS returning the User
	back to the Client that started the interaction. After a redirect
	back from the GS, the Client may be able to securely verify the
	returning User is the same as the User the Client redirected to the
	GS by verifying a unique Completion URI is associated with a browser
	cookie set prior to the redirection. Clients that are not able to
	securely verify the returning User, or do not want to, verify the
	User by making a Verify Grant call to the GS, passing the Interaction
	Nonce. The Client signals to the GS that it requires an Interaction
	Nonce by setting interaction.verify to true. Following is the
	Redirect Interaction sequence:
	1. If not interaction.verify, the Client creates a unique
	Completion URI.
	2. The Client creates a Grant Request setting interaction.type to
	"redirect" and interaction.completion_uri to the Completion URI,
	and makes a Create Grant request.
	3. The GS creates a Grant with a unique Grant URI and Authorization
	URI and binds them to the Completion URI.
	4. The GS creates an Interaction Response setting interaction.type		This document defines three interaction modes: "redirect",
	to "redirect" and interaction.authorization_uri to the		"indirect", and "user_code". Extensions may define additional
	Authorization URI and returns it to the Client.		interaction modes.
	5. If not interaction.verify, the Client creates and sets a a		The "global" attribute is reserved in the interaction object for
	unique completion browser cookie and binds it to the completion		attributes that apply to all interaction modes.
	URI. The cookie MUST not be able to be used to derive the
	Completion URI.
	6. The Client redirects the User's browser to the Authorization URI		7.1. "redirect" mode
	using any available browser redirect mechanism.
	7. The GS locates the Grant bound to the Authorization URI.		A Redirect Interaction is characterized by the Client redirecting the
			User's browser to the GS, the GS interacting with the User, and then
			GS redirecting the User's browser back to the Client. The GS
			correlates the Grant Request with the unique authorization_uri, and
			the Client correlates the Grant Request with the unique redirect_uri.
	8. The GS interacts with the User.		7.1.1. request "interaction" object contains:
	9. If interaction.verify, the GS creates an Interaction Nonce,		*redirect_uri* a grant request request unique URI at the Client that
	binds it to the Grant, and appends it to the Completion URI as		the GS will return the User to. This attribute is REQUIRED.
	the "nonce" query parameter.
	10. The GS redirects the User's browser to the Completion URI using		7.1.2. response "interaction" object contains:
	any available browser redirect mechanism.
	11. If not interaction.verify, the Client confirms the completion		*authorization_uri* a grant request request unique URI at the GS that
	browser cookie is bound to the Completion URI.		the Client will redirect the User to. This attribute is REQUIRED.
	12. If interaction.verify, the Client makes a Verify Grant call with		7.2. "indirect" mode
	the Interaction Nonce, and the Grant.
	A GS MUST support the Redirect Interaction type.		An Indirect Interaction is characterized by the Client causing the
			User's browser to load the short_uri at GS, the GS interacting with
			the User, and then the GS MAY optionally redirecting the User's
			Browser to a completion_uri. There is no mechanism for the GS to
			redirect the User's browser back to the Client. Examples of how the
			Client may initiate the interaction are encoding the short_uri as a
			code scannable by the User's mobile device, or launching a system
			browser from a command line interface (CLI) application.
	7.2. Indirect Interaction		The "indirect" mode is susceptible to session fixation attacks. See
			TBD in the Security Considerations for details.
	An Indirect Interaction is characterized by the GS not being able to		7.2.1. request "interaction" object contains:
	return the User back to the Client that started the interaction.
	There are two mechanisms for a User to identify the Client's Create
	Grant request at the GS: Short URI or User Code.
	1. Generation		*completion_uri* an OPTIONAL URI that the GS will redirect the User's
			browser to after GS interaction.
	1. The GS generates a Short URI and User Code unique to the		7.2.2. response "interaction" object contains:
	Grant.
	2. The GS sends the Short URI, Code URI, and User Code to the		*short_uri* the URI the Client will cause to load in the User's
	Client.		browser. The URI SHOULD be short enough to be easily encoded in a
			scannable code. [Editor: recommend a length?]
	2. Display		7.3. "user_code" mode
	1. If possible, the Client MAY display the Short URI to the User		An Indirect Interaction is characterized by the Client displaying a
	as a scannable code such as a [QR_Code]. The User MAY then		code and a URI for the User to load in a browser and then enter the
	scan the image that will open the Short URI on the User's		code.
	scanning device.
	2. The Client MAY optionally launch a system browser to open the		7.3.1. request "interaction" object contains:
	Short URI.
	3. The Client MUST display the User Code and instructions to		*completion_uri* an OPTIONAL URI that the GS will redirect the User's
	enter it at the Code URI. The User MAY navigate a browser on		browser to after GS interaction.
	a separate device to the Code URI.
	If the User arrived at the GS via the Short URI, the GS will use the		7.3.2. response "interaction" object contains:
	Short URI to identify the Create Grant request, and then authenticate
	the User.
	If the User arrived at the GS via the Code URI, the GS will		*code* the code the Client displays to the User to enter at the
	authenticate the User, and then prompt the User to enter the User		display_uri. This attribute is REQUIRED.
	Code, which the GS will then use to identify the Create Grant
	request.
	[Editor: we may need to include interaction types for iOS and Android		*display_uri* the URI the Client displays to the User to load in a
	as the mobile OS APIs evolve.]		browser to enter the code.
	8. RS Access		8. RS Access
	This document specifies three different mechanisms for the Client to		This document specifies three different mechanisms for the Client to
	access an RS ("bearer", "jose", and "jose+body"). The "bearer"		access an RS ("bearer", "jose", and "jose+body"). The "bearer"
	mechanism is defined in {BearerToken}. The "jose" and "jose+body"		mechanism is defined in {BearerToken}. The "jose" and "jose+body"
	mechanisms are proof-of-possession mechanisms and are defined in		mechanisms are proof-of-possession mechanisms and are defined in
	Section 10.2.2 and Section 10.2.3 respectively. Additional proof-of-		Section 10.2.2 and Section 10.2.3 respectively. Additional proof-of-
	possession mechanisms may be defined in other documents. The		possession mechanisms may be defined in other documents. The
	mechanism the Client is to use with an RS is the Response JSON		mechanism the Client is to use with an RS is the Response JSON
	authorization.mechanism attribute Section 6.4.3.		authorization.mechanism attribute Section 6.4.4.
	8.1. Bearer Token		8.1. Bearer Token
	If the access mechanism is "bearer", then the Client accesses the RS		If the access mechanism is "bearer", then the Client accesses the RS
	per Section 2.1 of [RFC6750]		per Section 2.1 of [RFC6750]
	A non-normative example of the HTTP request headers follows:		A non-normative 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 49, line 4 ¶		skipping to change at page 46, line 39 ¶
	- An extension can define new objects in the Grant Request and		- An extension can define new objects in the Grant Request and
	Grant Response JSON.		Grant Response JSON.
	* *Top Level*		* *Top Level*
	- Top level objects SHOULD only be defined to represent		- Top level objects SHOULD only be defined to represent
	functionality other the existing top level objects and		functionality other the existing top level objects and
	attributes.		attributes.
	* *"client" Object*		* *"client" Object*
	- Additional information about the Client that the GS would		- Additional information about the Client that the GS would
	require related to an extension.		require related to an extension.
	* *"user" Object*		* *"user" Object*
	- Additional information about the User that the GS would require		- Additional information about the User that the GS would require
	related to an extension.		related to an extension.
	* *"authorization" Object*		* *"authorization" Object*
	- Additional types of authorizations in addition to OAuth 2.0		- Additional authorization schemas in addition to OAuth 2.0
	scopes and RAR.		scopes and RAR.
	* *"claims" Object*		* *"claims" Object*
	- Additional types of identity claims in addition to OpenID		- Additional claim schemas in addition to OpenID Connect claims
	Connect claims and Verified Credentials.		and Verified Credentials.
	* *Interaction types*		* *interaction modes*
	- Additional types of interactions a Client can start with the		- Additional types of interactions a Client can start with the
	User.		User.
	* *Continuous Authentication*		* *Continuous Authentication*
	- An extension could define a mechanism for the Client to		- An extension could define a mechanism for the Client to
	regularly provide continuous authentication signals and receive		regularly provide continuous authentication signals and receive
	responses.		responses.
	skipping to change at page 53, line 15 ¶		skipping to change at page 51, line 4 ¶
	information that is opaque to the Client - so it has all the		information that is opaque to the Client - so it has all the
	features of a handle, plus it can be the URL that is resolved to		features of a handle, plus it can be the URL that is resolved to
	manipulate a Grant or an Authorization. As the Grant URI and AZ		manipulate a Grant or an Authorization. As the Grant URI and AZ
	URI are defined to start with the GS URI, the Client (and GS)		URI are defined to start with the GS URI, the Client (and GS)
	can easily determine which GS a Grant or Authorization belong		can easily determine which GS a Grant or Authorization belong
	to. URIs also enable a RESTful interface to the GS		to. URIs also enable a RESTful interface to the GS
	functionality.		functionality.
	15. *Why use the OPTIONS verb on the GS URI? Why not use a .well-		15. *Why use the OPTIONS verb on the GS URI? Why not use a .well-
	known mechanism?*		known mechanism?*
	Having the GS URI endpoint respond to the metadata allows the GS		Having the GS URI endpoint respond to the metadata allows the GS
	to provide Client specific results using the same Client		to provide Client specific results using the same Client
	authentication used for other requests to the GS. It also		authentication used for other requests to the GS. It also
	reduces the risk of a mismatch between what the advertised		reduces the risk of a mismatch between what the advertised
	metadata, and the actual metadata. A .well-known discovery		metadata, and the actual metadata. A .well-known discovery
	mechanism may be defined to resolve from a hostname to the GS		mechanism may be defined to resolve from a hostname to the GS
	URI.		URI.
	16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*		16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*
	Maybe there are no use cases for them [that the editor knows		Maybe there are no use cases for them [that the editor knows
	of], but the GS can not implement, and they are available if use		of], but the GS can not implement, and they are available if use
	cases come up.		cases come up.
			17. *Why have both Client ID and Client Handle?*
			While they both refer to a Client in the protocol, the Client ID
			refers to a pre-registered client,and the Client Handle is
			specific to an instance of a Dynamic Client. Using separate
			terms clearly differentiates which identifier is being presented
			to the GS.
	13. Acknowledgments		13. 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.
	14. IANA Considerations		14. IANA Considerations
	skipping to change at page 58, line 5 ¶		skipping to change at page 56, line 5 ¶
	* added Verify Grant API and Interaction Nonce		* added Verify Grant API and Interaction Nonce
	* replaced Refresh AuthZ with Read AuthZ. Read and refresh are same		* replaced Refresh AuthZ with Read AuthZ. Read and refresh are same
	operation.		operation.
	A.7. draft-hardt-xauth-protocol-06		A.7. draft-hardt-xauth-protocol-06
	* fixup examples to match specification		* fixup examples to match specification
			A.8. draft-hardt-xauth-protocol-07
			* refactored interaction request and response syntax, and enabled
			interaction mode negotiation
			* generation of client handle by GS for dynamic clients
			* renamed title to Grant Negotiation and Authorization Protocol.
			Preserved draft-hardt-xauth-protocol filename to ease tracking
			changes.
			* changed Authorizations to be key / value pairs (aka dictionary)
			instead of a JSON array
	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 this protocol and OAuth 2.0 and OpenID		The major changes between this protocol and OAuth 2.0 and OpenID
	Connect are:		Connect are:
	* The Client allows uses a private key to authenticate in this		* The Client allows uses a private key to authenticate in this
	protocol instead of the client secret in OAuth 2.0 and OpenID		protocol instead of the client secret in OAuth 2.0 and OpenID
	Connect.		Connect.
End of changes. 77 change blocks.
	314 lines changed or deleted		254 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/