< draft-hardt-xauth-protocol-04.txt		draft-hardt-xauth-protocol-05.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 19 February 2020		Intended status: Standards Track 7 March 2020
	Expires: 22 August 2020		Expires: 8 September 2020
	The XAuth Protocol		The XAuth Protocol
	draft-hardt-xauth-protocol-04		draft-hardt-xauth-protocol-05
	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 45 ¶		skipping to change at page 1, line 45 ¶
	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 22 August 2020.		This Internet-Draft will expire on 8 September 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6		1.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6		1.4. Notational Conventions . . . . . . . . . . . . . . . . . 7
	3. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Create and Verify Grant . . . . . . . . . . . . . . . . . 8
	3.2. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 8		2.2. Create and Read Grant - Redirect . . . . . . . . . . . . 10
	3.3. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 10		2.3. Create and Read Grant - Indirect . . . . . . . . . . . . 11
	3.4. Create and Update . . . . . . . . . . . . . . . . . . . . 10		2.4. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 11
	3.5. Create and Delete . . . . . . . . . . . . . . . . . . . . 12		2.5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 12
	3.6. Create, Discover, and Delete . . . . . . . . . . . . . . 14		2.6. Create and Update . . . . . . . . . . . . . . . . . . . . 13
	3.7. Create and Wait . . . . . . . . . . . . . . . . . . . . . 14		2.7. Create and Delete . . . . . . . . . . . . . . . . . . . . 15
	3.8. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 15		2.8. Create, Discover, and Delete . . . . . . . . . . . . . . 17
	3.9. Access Token Refresh . . . . . . . . . . . . . . . . . . 16		2.9. Create and Wait . . . . . . . . . . . . . . . . . . . . . 17
	3.10. GS API Table . . . . . . . . . . . . . . . . . . . . . . 16		2.10. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 18
	4. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 17		2.11. Resource Server Access . . . . . . . . . . . . . . . . . 19
	5. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		2.12. GS API Table . . . . . . . . . . . . . . . . . . . . . . 20
	5.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 18		3. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 20
	5.2. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 20		4. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.3. Update Grant . . . . . . . . . . . . . . . . . . . . . . 20		4.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 21
	5.4. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 21		4.2. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 24
	5.5. Request JSON . . . . . . . . . . . . . . . . . . . . . . 22		4.3. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 24
	5.5.1. "client" Object . . . . . . . . . . . . . . . . . . . 22		4.4. Update Grant . . . . . . . . . . . . . . . . . . . . . . 25
	5.5.2. "interaction" Object . . . . . . . . . . . . . . . . 22		4.5. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 26
	5.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 23		4.6. Request JSON . . . . . . . . . . . . . . . . . . . . . . 26
	5.5.4. "authorization" Object . . . . . . . . . . . . . . . 24		4.6.1. "client" Object . . . . . . . . . . . . . . . . . . . 26
	5.5.5. "authorizations" Object . . . . . . . . . . . . . . . 24		4.6.2. "interaction" Object . . . . . . . . . . . . . . . . 27
	5.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 24		4.6.3. "user" Object . . . . . . . . . . . . . . . . . . . . 28
	5.5.7. "reciprocal" Object . . . . . . . . . . . . . . . . . 24		4.6.4. "authorization" Object . . . . . . . . . . . . . . . 28
	5.6. Refresh Authorization . . . . . . . . . . . . . . . . . . 25		4.6.5. "authorizations" Object . . . . . . . . . . . . . . . 28
	5.7. Update Authorization . . . . . . . . . . . . . . . . . . 25		4.6.6. "claims" Object . . . . . . . . . . . . . . . . . . . 29
	5.8. Delete Authorization . . . . . . . . . . . . . . . . . . 26		4.6.7. "verification" Object . . . . . . . . . . . . . . . . 29
	5.9. GS Options . . . . . . . . . . . . . . . . . . . . . . . 26		4.7. Read Authorization . . . . . . . . . . . . . . . . . . . 29
	5.10. Grant Options . . . . . . . . . . . . . . . . . . . . . . 27		4.8. Update Authorization . . . . . . . . . . . . . . . . . . 30
	5.11. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 27		4.9. Delete Authorization . . . . . . . . . . . . . . . . . . 30
	5.12. Request Verification . . . . . . . . . . . . . . . . . . 27		4.10. GS Options . . . . . . . . . . . . . . . . . . . . . . . 30
	6. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 28		4.11. Grant Options . . . . . . . . . . . . . . . . . . . . . . 31
	7. GS API Responses . . . . . . . . . . . . . . . . . . . . . . 28		4.12. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 28		4.13. Request Verification . . . . . . . . . . . . . . . . . . 32
	7.2. Interaction Response . . . . . . . . . . . . . . . . . . 29		5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 32
	7.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 30		6. GS API Responses . . . . . . . . . . . . . . . . . . . . . . 32
	7.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 31		6.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 32
	7.4.1. "interaction" Object . . . . . . . . . . . . . . . . 31		6.2. Interaction Response . . . . . . . . . . . . . . . . . . 34
	7.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 32		6.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 34
	7.4.3. "authorization" Object . . . . . . . . . . . . . . . 32		6.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 35
	7.4.4. "authorizations" Object . . . . . . . . . . . . . . . 33		6.4.1. "interaction" Object . . . . . . . . . . . . . . . . 35
	7.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 33		6.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 36
	7.4.6. "reciprocal" Object . . . . . . . . . . . . . . . . . 33		6.4.3. "authorization" Object . . . . . . . . . . . . . . . 36
	7.4.7. Interaction Types . . . . . . . . . . . . . . . . . . 34		6.4.4. "authorizations" Object . . . . . . . . . . . . . . . 36
	7.4.8. Signing and Encryption . . . . . . . . . . . . . . . 34		6.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 36
	7.5. Response Verification . . . . . . . . . . . . . . . . . . 34		6.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 37
	8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 35		6.5.1. Signing and Encryption . . . . . . . . . . . . . . . 38
	8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 35		6.6. Response Verification . . . . . . . . . . . . . . . . . . 38
	9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 35		7. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 38
	10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 35		7.1. Redirect Interaction . . . . . . . . . . . . . . . . . . 38
	10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 36		7.2. Indirect Interaction . . . . . . . . . . . . . . . . . . 40
	10.1.1. Authorization Header . . . . . . . . . . . . . . . . 36		8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 37		8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 41
	10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 38		9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 41
	10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 39		10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 41
	10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 39		10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 42
	10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 39		10.1.1. Authorization Header . . . . . . . . . . . . . . . . 42
	10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 40		10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 43
	10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 41		10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 44
	10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 42		10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 45
	10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 42		10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 45
	10.5. Response Encryption . . . . . . . . . . . . . . . . . . 42		10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 45
	11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42		10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 46
	12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 43		10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 47
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47		10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 48
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 48
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 48		10.5. Response Encryption . . . . . . . . . . . . . . . . . . 48
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 48		11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 48
	16.1. Normative References . . . . . . . . . . . . . . . . . . 48		12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	16.2. Informative References . . . . . . . . . . . . . . . . . 49		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 50		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 50		15. Security Considerations . . . . . . . . . . . . . . . . . . . 54
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 50		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 51		16.1. Normative References . . . . . . . . . . . . . . . . . . 54
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51		16.2. Informative References . . . . . . . . . . . . . . . . . 55
	A.5. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51		Appendix A. Document History . . . . . . . . . . . . . . . . . . 56
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 51		A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 56
	Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 53		A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 56
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53		A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 57
			A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 57
			A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 57
			A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 57
			Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 58
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59
	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 4, line 50 ¶		skipping to change at page 5, line 7 ¶
	This protocol centers around a Grant, a representation of the		This protocol centers around a Grant, a representation of the
	collection of user identity claims and/or resource authorizations the		collection of user identity claims and/or resource authorizations the
	Client is requesting, and the resulting identity claims and/or		Client is requesting, and the resulting identity claims and/or
	resource authorizations granted by the Grant Server.		resource authorizations granted by the Grant Server.
	[Editor: suggestions on how to improve this are welcome!]		[Editor: suggestions on how to improve this are welcome!]
	[Editor: suggestions for other names than XAuth are welcome!]		[Editor: suggestions for other names than XAuth are welcome!]
	2. Terminology		1.1. Parties
	2.1. Parties
	The parties and their relationships to each other:		The parties and their relationships to each other:
	+--------+ +------------+		+--------+ +------------+
	| User | | Resource |		| User | | Resource |
	| | | Owner (RO) |		| | | Owner (RO) |
	+--------+ +------------+		+--------+ +------------+
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ / |		| \ / |
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 33 ¶
	| |-------------------------->| |		| |-------------------------->| |
	| |<--------------------------| |		| |<--------------------------| |
	+--------+ +------------+		+--------+ +------------+
	* *User* - the person interacting with the Client who has delegated		* *User* - the person interacting with the Client who has delegated
	access to identity claims about themselves to the Grant Server		access to identity claims about themselves to the Grant Server
	(GS), and can authenticate at the GS.		(GS), and can authenticate at the GS.
	* *Client* - requests a Grant from the GS to access one or more		* *Client* - requests a Grant from the GS to access one or more
	Resource Servers (RSs), and/or identity claims about the User.		Resource Servers (RSs), and/or identity claims about the User.
	The Client can create, retrieve, update, and delete a Grant. When		The Client can create, verify, retrieve, update, and delete a
	a Grant is created, the Client receives from the GS the granted		Grant. When a Grant is created, the Client receives from the GS
	access token(s) for the RS(s), and identity claims about the User.		the granted access token(s) for the RS(s), and identity claims
	The Client uses an access token to access the RS. There are two		about the User. The Client uses an access token to access the RS.
	types of Clients: Registered Clients and Dynamic Clients. All		There are two types of Clients: Registered Clients and Dynamic
	Clients have a key to authenticate with the Grant Server.		Clients. All Clients have a key to authenticate with the Grant
			Server.
	* *Registered Client* - a Client that has registered with the GS and		* *Registered Client* - a Client that has registered with the GS and
	has a Client ID to identify itself, and can prove it possesses a		has a Client ID to identify itself, and can prove it possesses a
	key that is linked to the Client ID. The GS may have different		key that is linked to the Client ID. The GS may have different
	policies for what different Registered Clients can request. A		policies for what different Registered Clients can request. A
	Registered Client MAY be interacting with a User.		Registered Client MAY be interacting with a User.
	* *Dynamic Client* - a Client that has not been registered with the		* *Dynamic Client* - a Client that has not been registered with the
	GS, and each instance will generate it's own key pair so it can		GS, and each instance will generate it's own key pair so it can
	prove it is the same instance of the Client on subsequent		prove it is the same instance of the Client on subsequent
	requests, and to requests of a Resource Server. A single-page		requests, and to requests of a Resource Server that require proof-
	application with no server is an example of a Dynamic Client. A		of-possession access. A single-page application with no active
	Dynamic Client MUST be interacting with a User.		server component is an example of a Dynamic Client. A Dynamic
			Client MUST be interacting with a User.
	* *Grant Server* (GS) - manages Grants for access to APIs at RSs and		* *Grant Server* (GS) - manages Grants for access to APIs at RSs and
	release of identity claims about the User. The GS may require		release of identity claims about the User. The GS may require
	explicit consent from the RO or User to provide these to the		explicit consent from the RO or User to provide these to the
	Client. An GS may support Registered Clients and/or Dynamic		Client. A GS may support Registered Clients and/or Dynamic
	Clients. The GS is a combination of the Authorization Server (AS)		Clients. The GS is a combination of the Authorization Server (AS)
	in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect.		in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect.
	* *Resource Server* (RS) - has API resources that require an access		* *Resource Server* (RS) - has API resources that require an access
	token from the GS. Owned by the Resource Owner.		token from the GS. Some, or all of the resources are owned by the
			Resource Owner.
	* *Resource Owner* (RO) - owns resources at the RS, and has		* *Resource Owner* (RO) - owns resources at the RS, and has
	delegated RS access management to the GS. The RO may be the same		delegated RS access management to the GS. The RO may be the same
	entity as the User, or may be a different entity that the GS		entity as the User, or may be a different entity that the GS
	interacts with independently. GS and RO interactions are out of		interacts with independently. GS and RO interactions are out of
	scope of this document.		scope of this document.
	2.2. Reused Terms		1.2. Reused Terms
	* *access token* - an access token as defined in [RFC6749]		* *access token* - an access token as defined in [RFC6749]
	Section 1.4.		Section 1.4.
	* *Claim* - a Claim as defined in [OIDC] Section 5. Claims may be		* *Claim* - a Claim as defined in [OIDC] Section 5. Claims may be
	issued by the GS, or by other issuers.		issued by the GS, or by other issuers.
	* *Client ID* - a GS unique identifier for a Registered Client as		* *Client ID* - a GS unique identifier for a Registered Client as
	defined in [RFC6749] Section 2.2.		defined in [RFC6749] Section 2.2.
	* *ID Token* - an ID Token as defined in [OIDC] Section 2.		* *ID Token* - an ID Token as defined in [OIDC] Section 2.
	* *NumericDate* - a NumericDate as defined in [RFC7519] Section 2.		* *NumericDate* - a NumericDate as defined in [RFC7519] Section 2.
	* *authN* - short for authentication.		* *authN* - short for authentication.
	* *authZ* - short for authorization.		* *authZ* - short for authorization.
	2.3. New Terms		1.3. New Terms
	* *GS URI* - the endpoint at the GS the Client calls to create a		* *GS URI* - the endpoint at the GS the Client calls to create a
	Grant. The unique identifier for the GS.		Grant, and is the unique identifier for the GS.
	* *Grant* - the user identity claims and/or RS authorizations the GS		* *Grant* - the user identity claims and/or RS authorizations the GS
	has granted to the Client.		has granted to the Client.
	* *Grant URI* - the URI that represents the Grant. The Grant URI		* *Grant URI* - the URI that represents the Grant. The Grant URI
	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.
	* *AuthZ URI* - the URI that represents the Authorization the Client		* *Authorization URI* (AZ URI) - the URI that represents the
	was granted by the RO. The AuthZ URI MUST start with the GS URI.		Authorization the Client was granted by the RO. The AZ URI MUST
	The AuthZ URI is used to refresh, update, and delete an access		start with the GS URI. The AZ URI is used to read, update, and
	token.		delete an access token.
	* *interaction* - [Editor: what do we really mean by this term?]		* *Redirect Interaction* - characterized by the GS returning the
			User back to the Client that started the interaction.
	3. Sequences		* *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
			outstanding Create Grant request in an Indirect Interaction.
			1.4. Notational Conventions
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			specification are to be interpreted as described in [RFC2119].
			Certain security-related terms are to be understood in the sense
			defined in [RFC4949]. These terms include, but are not limited to,
			"attack", "authentication", "authorization", "certificate",
			"confidentiality", "credential", "encryption", "identity", "sign",
			"signature", "trust", "validate", and "verify".
			Unless otherwise noted, all the protocol parameter names and values
			are case sensitive.
			Some protocol parameters are parts of a JSON document, and are
			referred to in JavaScript notation. For example, foo.bar refers to
			the "bar" boolean attribute in the "foo" object in the following
			example JSON document:
			{
			"foo" : {
			"bar": true
			}
			}
			2. Sequences
	Before any sequence, the Client needs to be manually or		Before any sequence, the Client needs to be manually or
	programmatically configured for the GS. See GS Options Section 5.9		programmatically configured for the GS. See GS Options Section 4.10
	for details on acquiring GS metadata.		for details on acquiring GS metadata.
	[Editor: a plethora of sequences are included to illustrate all the		[Editor: a plethora of sequences are included to illustrate all the
	different actions. Many of these could potentially be moved to a use		different use cases that are supported. Many sequences are similar,
	case document in the future.]		and show a slightly different sequence that can support different use
			cases. These could potentially be moved to a use case document in
			the future.]
	3.1. Create Grant		2.1. Create and Verify Grant
	The Client requests a Grant from the GS that requires User		A Dynamic Client wants a Grant from the User using a Redirect
	interaction:		Interaction:
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | (2) |
	| |<--- Interaction Response ---(3)--| eval |
	| | | |		| | | |
	| |--(4)--- Read Grant ------------->| | +------+		| |<--- Interaction Response ---(2)--| | +------+
	| | | | | User |		| | | | | User |
	| |--(5)--- Interaction Transfer --- | - - - | ------->| |		| |--(3)--- Interaction Transfer --- | - - - | ------->| |
	| | | |<--(6)-->| |		| | | | | |
			| | | |<--(4)-->| |
	| | | | authN | |		| | | | authN | |
	| | | |<--(7)-->| |		| | | |<--(5)-->| |
	| | | | authZ | |		| | | | authZ | |
	| |<--- Interaction Transfer ---(8)- | - - - | --------| |		| |<--- Interaction Transfer ---(6)- | - - - | --------| |
	| | | | | |		| | | | | |
	| |<--------- Grant Response ---(9)--| | +------+		| |--(7)--- Verify Grant ----------->| | +------+
			| | | |
			| |<--------- Grant Response ---(8)--| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 5.1)		1. *Create Grant* The Client creates a Request JSON document
	and sends it with an HTTP POST to the GS GS URI.		Section 4.6 and makes a Create Grant request (Section 4.1) by
			sending the JSON with an HTTP POST to the GS URI.
	2. *Grant Request Evaluation* The GS processes the request to		2. *Interaction Response* The GS determines that interaction with
	determine if it will send a Interaction Response, Wait Response,		the User is required and sends an Interaction Response
	or a Grant Response. The GS determines that interaction with the		(Section 6.2) containing the Grant URI and an interaction object.
	User is required and sends an Interaction Response. (For
	readability, this step is not described in the following
	sequences)
	3. *Interaction Response* The GS sends an Interaction Response		3. *Interaction Transfer* The Client redirects the User to the
	(Section 7.2) containing the Grant URI and an interaction object.		Redirect URI at the GS.
	4. *Read Grant* The Client does an HTTP GET of the Grant URI		4. *User Authentication* The GS authenticates the User.
	(Section 5.2).
	5. *Interaction Transfer* The Client transfers User interaction to		5. *User Authorization* If required, the GS interacts with the User
			to determine which identity claims and/or authorizations in the
			Grant Request are to be granted.
			6. *Interaction Transfer* The GS redirects the User to the
			Completion URI at the Client, passing an Interaction Nonce.
			7. *Read Grant* The Client creates a JSON document containing a
			verification object Section 4.6.7 and does a Verify Grant
			Section 4.2 request by HTTP PATCH with the document to the Grant
			URI.
			8. *Grant Response* The GS responds with a Grant Response
			(Section 6.1).
			2.2. Create and Read Grant - Redirect
			A Registered Client wants a Grant from the User using a Redirect
			Interaction:
			+--------+ +-------+
			| Client | | GS |
			| |--(1)--- Create Grant ----------->| |
			| | | |
			| |<--- Interaction Response ---(2)--| |
			| | | |
			| |--(3)--- Read Grant ------------->| | +------+
			| | | | | User |
			| |--(4)--- Interaction Transfer --- | - - - | ------->| |
			| | | | | |
			| | | |<--(5)-->| |
			| | | | authN | |
			| | | |<--(6)-->| |
			| | | | authZ | |
			| |<--------- Grant Response ---(7)--| | | |
			| | | | | |
			| |<--- Interaction Transfer ---(8)- | - - - | --------| |
			| | | | | |
			+--------+ +-------+ +------+
			1. *Create Grant* The Client makes a Create Grant request
			(Section 4.1) to the GS URI.
			2. *Interaction Response* The GS determines that interaction with
			the User is required and sends an Interaction Response
			(Section 6.2) containing the Grant URI and an interaction object.
			3. *Read Grant* The Client does an HTTP GET of the Grant URI
			(Section 4.3).
			4. *Interaction Transfer* The Client transfers User interaction to
	the GS.		the GS.
	6. *User Authentication* The GS authenticates the User.		5. *User Authentication* The GS authenticates the User.
	7. *User Authorization* If required, the GS interacts with the User		6. *User Authorization* If required, the GS interacts with the User
	to determine which identity claims and/or authorizations in the		to determine which identity claims and/or authorizations in the
	Grant Request are to be granted.		Grant Request are to be granted.
	8. *Interaction Transfer* The GS transfers User interaction to the		7. *Grant Response* The GS responds with a Grant Response
	Client.		(Section 6.1).
	9. *Grant Response* The GS responds with a Grant Response		8. *Interaction Transfer* The GS redirects the User to the
	(Section 7.1).		Completion URI of the Client. The Client verifies it is the same
			User that it transferred to the GS.
	3.2. Reciprocal Grant		2.3. Create and Read Grant - Indirect
			A Registered Client wants a Grant from the User using an Indirect
			Interaction:
			+--------+ +-------+
			| Client | | GS |
			| |--(1)--- Create Grant ----------->| |
			| | | |
			| |<--- Interaction Response ---(2)--| |
			| | | |
			| |--(3)--- Read Grant ------------->| | +------+
			| | | | | User |
			| |--(4)--- Interaction Transfer --- | - - - | ------->| |
			| | | | | |
			| | | |<--(5)-->| |
			| | | | authN | |
			| | | |<--(6)-->| |
			| | | | authZ | |
			| |<--------- Grant Response ---(7)--| | | |
			+--------+ | | | |
			| | | |
			+--------+ | | | |
			| Info |<--- Interaction Transfer ---(8)- | - - - | --------| |
			| Server | | | | |
			+--------+ +-------+ +------+
			The sequence is the same except:
			* In step (4) the User either scans a bar code or uses a separate
			device to navigate to the Code URI and enters the User Code.
			* In step (8) the GS redirects the User to the Information URI
			provided by the Client.
			2.4. Reciprocal Grant
	Party A and Party B are both a Client and a GS, and each Client would		Party A and Party B are both a Client and a GS, and each Client would
	like a Grant for the other GS. Party A starts off being the Client		like a Grant for the other GS. The sequence starts off the same as
	per Create Grant Section 3.1. Party B then includes a Reciprocal		in Section 2.2, but Party B makes a Create Grant Request before
	Request in its Grant Response. Party A then gets authorization from		sending a Grant Response:
	the User and returns a Grant URI to Party B. Party A and B swap
	roles, and Party B's Client obtains the Grant from Party A's GS.
	Party A Party B		Party A Party B
	+--------+ +--------+		+--------+ +--------+
	| Client | | GS |		| Client | | GS |
	~ ~ ~ ~ ~ ~ Same as steps 1 - 8 of ~ ~ ~ ~ ~ ~		~ ~ ~ ~ ~ ~ Same as steps 1 - 6 of ~ ~ ~ ~ ~ ~
	+------+ | | Create Grant above | |		+------+ | | Create and Read Grant above | |
	| User | | | | |		| User | | | | |
	| |<----- | - - - | -- Interaction Transfer ------- | |		| | | GS |<--------- Create Grant ---(1)---| Client |
	| | | | | |		| | | | | |
	| | | |<------- Grant Response ---(1)---| |		| | | |<------- Grant Response ---(2)---| |
	| | | | Reciprocal Grant Request | |		| | | | | |
	| |<-(2)->| | | |		| |<----- | - - - | -- Interaction Transfer --(3)---| |
	| | AuthZ | |---(3)--- Update Grant --------->| |		| | | | | |
	+------+ | | Reciprocal Grant Response | |		| |<-(4)->| | | |
	| | | |		| | AuthZ | | | |
	| |<-- Empty Grant Response ---(4)--| |		+------+ | GS |--(5)--- Grant Response -------->| Client |
	| | | |
	+--------+ (5) Swap Roles +--------+
	| GS | | Client |
	| |<------------ Read Grant ---(6)--| |
	| | | |
	| |--(7)--- Grant Response -------->| |
	| | | |		| | | |
	+--------+ +--------+		+--------+ +--------+
	1. *Grant Response* Party B responds with a Grant Response including		1. *Create Grant* Party B creates a Grant Request (Section 4.1) with
	a Reciprocal Object Section 7.4.6 requesting its own Grant.		user.reciprocal set to the Party B Grant URI that will be in the
			step (2) Grant Response, and sends it with an HTTP POST to the
	2. *User Authorization* If required, Party A interacts with the User		Party A GS URI. This enables Party A to link the reciprocal
	to determine which identity claims and/or authorizations in the		Grants.
	Grant Request are to be granted to Party B.
	3. *Update Grant* Party A sends an Update Grant request containing
	the Grant URI in the Reciprocal object Section 5.5.7.
	4. *Grant Response* Party B responds with an Empty Grant Response as		2. *Grant Response* Party B responds to Party A's Create Grant
	there were no other requests in the Update Grant.		Request with a Grant Response that includes the Party B Grant
			URI.
	5. *Swap Roles* Party A now acts as a GS, Party B as a Client.		3. *Interaction Transfer* Party B redirects the User to the
			Completion URI at Party A.
	6. *Read Grant* Party B does an HTTP GET of the Grant URI		4. *User Authorization* If required, Party A interacts with the User
	(Section 5.2).		to determine which identity claims and/or authorizations in Party
			B's Create Grant Request are to be granted.
	7. *Grant Response* Party A responds with a Grant Response		5. *Grant Response* Party A responds with a Grant Response
	(Section 7.1).		(Section 6.1).
	3.3. GS Initiated Grant		2.5. GS Initiated Grant
	The User is at the GS, and wants to interact with a Registered		The User is at the GS, and wants to interact with a Registered
	Client. The GS can redirect the User to the Client:		Client. The GS can redirect the User to the Client:
	+--------+ +-------+ +------+		+--------+ +-------+ +------+
	| Client | | GS | | User |		| Client | | GS | | User |
	| | | |<--(1)-->| |		| | | |<--(1)-->| |
	| | | | | |		| | | | | |
	| |<----- GS Initiation Redirect --- | - - - | --(2)---| |		| |<----- GS Initiation Redirect --- | - - - | --(2)---| |
	| (3) | | | | |		| (3) | | | | |
	skipping to change at page 10, line 34 ¶		skipping to change at page 13, line 29 ¶
	provide. The GS creates a Grant and corresponding Grant URI.		provide. The GS creates a Grant and corresponding Grant URI.
	2. *GS Initiated Redirect* The GS redirects the User to the Client's		2. *GS Initiated Redirect* The GS redirects the User to the Client's
	interaction_uri, adding a query parameter with the name "Grant		interaction_uri, adding a query parameter with the name "Grant
	URI" and the value being the URL encoded Grant URI.		URI" and the value being the URL encoded Grant URI.
	3. *Client Verification* The Client verifies the Grant URI is from		3. *Client Verification* The Client verifies the Grant URI is from
	an GS the Client trusts, and starts with the GS GS URI.		an GS the Client trusts, and starts with the GS GS URI.
	4. *Read Grant* The Client does an HTTP GET of the Grant URI		4. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 5.2).		(Section 4.3).
	5. *Grant Response* The GS responds with a Grant Response		5. *Grant Response* The GS responds with a Grant Response
	(Section 7.1).		(Section 6.1).
	See Section 6 for more details.		See Section 5 for more details.
	3.4. Create and Update		2.6. Create and Update
	The Client requests an identity claim to determine who the User is.		The Client requests an identity claim to determine who the User is.
	Once the Client learns who the User is, and the Client updates the		Once the Client learns who the User is, and the Client updates the
	Grant for additional identity claims which the GS prompts the User		Grant for additional identity claims which the GS prompts the User
	for and returns to the Client. Once those are received, the Client		for and returns to the Client. Once those are received, the Client
	updates the Grant with the remaining identity claims required.		updates the Grant with the remaining identity claims required.
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | "interaction"."keep":true | |		| | interaction.keep:true | |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| |		| |<--- Interaction Response ---(2)--| |
	| | | |		| | | |
	| |--(3)--- Read Grant ------------->| | +------+		| |--(3)--- Read Grant ------------->| | +------+
	| | | | | User |		| | | | | User |
	| |--(4)--- Interaction Transfer --- | - - - | ------->| |		| |--(4)--- Interaction Transfer --- | - - - | ------->| |
	| | | | | |		| | | | | |
	| | | |<--(5)-->| |		| | | |<--(5)-->| |
	| | | | authN | |		| | | | authN | |
	| |<--------- Grant Response ---(6)--| | | |		| |<--------- Grant Response ---(6)--| | | |
	| (7) | | | | |		| (7) | | | | |
	| eval |--(8)--- Update Grant ----------->| | | |		| eval |--(8)--- Update Grant ----------->| | | |
	| | "interaction"."keep":true | |<--(9)-->| |		| | interaction.keep:true | |<--(9)-->| |
	| | | | authZ | |		| | | | authZ | |
	| |<--------- Grant Response --(10)--| | | |		| |<--------- Grant Response --(10)--| | | |
	| (11) | | | | |		| (11) | | | | |
	| eval |--(12)-- Update Grant ----------->| | | |		| eval |--(12)-- Update Grant ----------->| | | |
	| | "interaction"."keep":false | |<--(13)->| |		| | interaction.keep:false | |<--(13)->| |
	| | | | authZ | |		| | | | authZ | |
	| | | | | |		| | | | | |
	| |<--- Interaction Transfer --(14)- | - - - | --------| |		| |<--- Interaction Transfer --(14)- | - - - | --------| |
	| | | | | |		| | | | | |
	| |<--------- Grant Response --(15)--| | +------+		| |<--------- Grant Response --(15)--| | +------+
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 5.1)		1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	including an identity claim and "interaction"."keep":true, and		including an identity claim and interaction.keep:true, and sends
	sends it with an HTTP POST to the GS GS URI.		it with an HTTP POST to the GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response		2. *Interaction Response* The GS sends an Interaction Response
	(Section 7.2) containing the Grant URI, an interaction object,		(Section 6.2) containing the Grant URI, an interaction object,
	and "interaction"."keep":true.		and interaction.keep:true.
	3. *Read Grant* The Client does an HTTP GET of the Grant URI		3. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 5.2).		(Section 4.3).
	4. *Interaction Transfer* The Client transfers User interaction to		4. *Interaction Transfer* The Client transfers User interaction to
	the GS.		the GS.
	5. *User Authentication* The GS authenticates the User.		5. *User Authentication* The GS authenticates the User.
	6. *Grant Response* The GS responds with a Grant Response		6. *Grant Response* The GS responds with a Grant Response
	(Section 7.1) including the identity claim from User		(Section 6.1) including the identity claim from User
	authentication and "interaction"."keep":true.		authentication and interaction.keep:true.
	7. *Grant Evaluation* The Client queries its User database and does		7. *Grant Evaluation* The Client queries its User database and does
	not find a User record matching the identity claim.		not find a User record matching the identity claim.
	8. *Update Grant* The Client creates an Update Grant Request		8. *Update Grant* The Client creates an Update Grant Request
	(Section 5.3) including the initial identity claims required and		(Section 4.4) including the initial identity claims required and
	"interaction"."keep":true, and sends it with an HTTP PUT to the		interaction.keep:true, and sends it with an HTTP PUT to the
	Grant URI.		Grant URI.
	9. *User AuthN* The GS interacts with the User to determine which		9. *User AuthN* The GS interacts with the User to determine which
	identity claims in the Update Grant Request are to be granted.		identity claims in the Update Grant Request are to be granted.
	10. *Grant Response* The GS responds with a Grant Response		10. *Grant Response* The GS responds with a Grant Response
	(Section 7.1) including the identity claims released by the User		(Section 6.1) including the identity claims released by the User
	and "interaction"."keep":true.		and interaction.keep:true.
	11. *Grant Evaluation* The Client evaluates the identity claims in		11. *Grant Evaluation* The Client evaluates the identity claims in
	the Grant Response and determines the remaining User identity		the Grant Response and determines the remaining User identity
	claim required.		claim required.
	12. *Update Grant* The Client creates an Update Grant Request		12. *Update Grant* The Client creates an Update Grant Request
	(Section 5.3) including the remaining required identity claims		(Section 4.4) including the remaining required identity claims
	and "interaction"."keep":false, and sends it with an HTTP PUT to		and interaction.keep:false, and sends it with an HTTP PUT to the
	the Grant URI.		Grant URI.
	13. *User AuthZ* The GS interacts with the User to determine which		13. *User AuthZ* The GS interacts with the User to determine which
	identity claims in the Update Grant Request are to be granted.		identity claims in the Update Grant Request are to be granted.
	14. *Interaction Transfer* The GS transfers User interaction to the		14. *Interaction Transfer* The GS transfers User interaction to the
	Client.		Client.
	15. *Grant Response* The GS responds with a Grant Response		15. *Grant Response* The GS responds with a Grant Response
	(Section 7.1) including the identity claims released by the		(Section 6.1) including the identity claims released by the
	User.		User.
	3.5. Create and Delete		2.7. Create and Delete
	The Client requests an identity claim to determine who the User is.		The Client requests an identity claim to determine who the User is.
	Once the Client learns who the User is, and the Client knows it has		Once the Client learns who the User is, and the Client knows it
	all the identity claims and authorizations needed, the Client deletes		already has all the identity claims and authorizations needed for the
	the Grant which prompts the GS to transfer the interaction back to		User, the Client deletes the Grant which prompts the GS to transfer
	the Client.		the interaction back to the Client. (If the Client did not already
			have what was needed, the Client would follow the Create and Update
			sequence Section 2.6 )
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | "interaction"."keep":true | |		| | interaction.keep:true | |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| |		| |<--- Interaction Response ---(2)--| |
	| | | |		| | | |
	| |--(3)--- Read Grant ------------->| | +------+		| |--(3)--- Read Grant ------------->| | +------+
	| | | | | User |		| | | | | User |
	| |--(4)--- Interaction Transfer --- | - - - | ------->| |		| |--(4)--- Interaction Transfer --- | - - - | ------->| |
	| | | | | |		| | | | | |
	| | | |<--(5)-->| |		| | | |<--(5)-->| |
	| | | | authN | |		| | | | authN | |
	| |<--------- Grant Response ---(6)--| | | |		| |<--------- Grant Response ---(6)--| | | |
	| (7) | | | | |		| (7) | | | | |
	| eval |--(8)--- Delete Grant ----------->| | | |		| eval |--(8)--- Delete Grant ----------->| | | |
	| |<------- Delete Response ---------| | | |		| |<------- Delete Response ---------| | | |
	| | | | | |		| | | | | |
	| |<--- Interaction Transfer ---(9)- | - - - | --------| |		| |<--- Interaction Transfer ---(9)- | - - - | --------| |
	| | | | | |		| | | | | |
	+--------+ +-------+ +------+		+--------+ +-------+ +------+
	1. *Create Grant* The Client creates a Grant Request (Section 5.1)		1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	including an identity claim and "interaction"."keep":true, and		including an identity claim and interaction.keep:true, and sends
	sends it with an HTTP POST to the GS GS URI.		it with an HTTP POST to the GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response		2. *Interaction Response* The GS sends an Interaction Response
	(Section 7.2) containing the Grant URI, an interaction object,		(Section 6.2) containing the Grant URI, an interaction object,
	and "interaction"."keep":true.		and interaction.keep:true.
	3. *Read Grant* The Client does an HTTP GET of the Grant URI		3. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 5.2).		(Section 4.3).
	4. *Interaction Transfer* The Client transfers User interaction to		4. *Interaction Transfer* The Client transfers User interaction to
	the GS.		the GS.
	5. *User Authentication* The GS authenticates the User.		5. *User Authentication* The GS authenticates the User.
	6. *Grant Response* The GS responds with a Grant Response		6. *Grant Response* The GS responds with a Grant Response
	(Section 7.1) including the identity claim from User		(Section 6.1) including the identity claim from User
	authentication and "interaction"."keep":true.		authentication and interaction.keep:true.
	7. *Grant Evaluation* The Client queries its User database and finds		7. *Grant Evaluation* The Client queries its User database and finds
	the User record matching the identity claim, and that no		the User record matching the identity claim, and that no
	additional claims or authorizations are required.		additional claims or authorizations are required.
	8. *Delete Grant* The Client no longer needs the Grant and decides		8. *Delete Grant* The Client no longer needs the Grant and decides
	to Delete Grant (Section 5.4) by sending an HTTP DELETE to the		to Delete Grant (Section 4.5) by sending an HTTP DELETE to the
	Grant URI. If the GS responds with success the Grant no longer		Grant URI. If the GS responds with success the Grant no longer
	exists.		exists.
	3.6. Create, Discover, and Delete		2.8. Create, Discover, and Delete
	The Client wants to discover if the GS has a User with a given		The Client wants to discover if the GS has a User with a given
	identifier. If not, it will abort the request and not transfer		identifier. If not, it will abort the request and not transfer
	interaction to the GS.		interaction to the GS.
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | "user"."exists":true | |		| | user.exists:true | |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| |		| |<--- Interaction Response ---(2)--| |
	| | "user"."exists":false | |		| | user.exists:false | |
	| | | |		| | | |
	| |--(3)--- Delete Grant ----------->| |		| |--(3)--- Delete Grant ----------->| |
	| |<------- Delete Response ---------| |		| |<------- Delete Response ---------| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 5.1)		1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	including an identity claim request, a User identifier, and		including an identity claim request, a User identifier, and
	"user"."exists":true. The Client sends it with an HTTP POST to		user.exists:true. The Client sends it with an HTTP POST to the
	the GS GS URI.		GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response		2. *Interaction Response* The GS sends an Interaction Response
	(Section 7.2) containing the Grant URI, an interaction object,		(Section 6.2) containing the Grant URI, an interaction object,
	and "user"."exists":false.		and user.exists:false.
	3. *Delete Grant* The Client determines the GS cannot fulfil its		3. *Delete Grant* The Client determines the GS cannot fulfil its
	Grant Request, and decides to Delete Grant (Section 5.4) by		Grant Request, and decides to Delete Grant (Section 4.5) by
	sending an HTTP DELETE to the Grant URI. If the GS responds with		sending an HTTP DELETE to the Grant URI. If the GS responds with
	success the Grant no longer exists.		success the Grant no longer exists.
	3.7. Create and Wait		2.9. Create and Wait
	The Client wants access to resources that require the GS to interact		The Client wants access to resources that require the GS to interact
	with the RO, which may not happen immediately, so the GS instructs		with the RO, which may not happen immediately, so the GS instructs
	the Client to wait and check back later.		the Client to wait and check back later.
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | |		| | | |
	| |<---------- Wait Response ---(2)--| | +------+		| |<---------- Wait Response ---(2)--| | +------+
	| (3) | | | | RO |		| (3) | | | | RO |
	| Wait | | |<--(4)-->| |		| Wait | | |<--(4)-->| |
	| | | | authZ | |		| | | | AuthZ | |
	| |--(5)--- Read Grant ------------->| | +------+		| |--(5)--- Read Grant ------------->| | +------+
	| | | |		| | | |
	| |<--------- Grant Response --(6)---| |		| |<--------- Grant Response --(6)---| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 5.1)		1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	and sends it with an HTTP POST to the GS GS URI.		and sends it with an HTTP POST to the GS GS URI.
	2. *Wait Response* The GS sends an Interaction Response		2. *Wait Response* The GS sends an Interaction Response
	(Section 7.3) containing the Grant URI and wait time.		(Section 6.3) containing the Grant URI and wait time.
	3. *Client Waits* The Client waits the wait time.		3. *Client Waits* The Client waits the wait time.
	4. *RO AuthZ* The GS interacts with the RO to determine which		4. *RO AuthZ* The GS interacts with the RO to determine which
	identity claims in the Grant Request are to be granted.		identity claims in the Grant Request are to be granted.
	5. *Read Grant* The Client does an HTTP GET of the Grant URI		5. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 5.2).		(Section 4.3).
	6. *Grant Response* The GS responds with a Grant Response		6. *Grant Response* The GS responds with a Grant Response
	(Section 7.1).		(Section 6.1).
	3.8. Read Grant		2.10. Read Grant
	The Client wants to acquire fresh identity claims and authorizations		The Client wants to re-acquire the identity claims and authorizations
	in the Grant. No User or RO interaction is required as no new		in the Grant. No User or RO interaction is required as no new
	consent or authorization is required.		consent or authorization is required.
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Read Grant ------------->| |		| |--(1)--- Read Grant ------------->| |
	| | | |		| | | |
	| |<--------- Grant Response --(2)---| |		| |<--------- Grant Response --(2)---| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Read Grant* The Client does an HTTP GET of the Grant URI		1. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 5.2).		(Section 4.3).
	2. *Grant Response* The GS responds with a Grant Response		2. *Grant Response* The GS responds with a Grant Response
	(Section 7.1) containing updated identity claims and		(Section 6.1) containing updated identity claims and
	authorizations.		authorizations.
	3.9. Access Token Refresh		2.11. Resource Server Access
	The Client has an access token and uses it to access resources at an		The Client received an AZ URI from the GS. The Client acquires an
	RS. The access token expires, and the Client acquires a fresh access		access token, calls the RS, and later the access token expires. The
	token from the GS.		Client then gets a fresh access token.
	+--------+ +----------+		+--------+ +-------+
	| Client | | Resource |		| Client | | GS |
	| |--(1)--- Access Resource --->| Server |		| |--(1)--- Read AuthZ ---------------------->| |
	| |<------- Resource Response --| (RS) |		| |<------- AuthZ Response -------------------| |
	| | | |		| | | |
	| |--(2)--- Access Resource --->| |		| | +----------+ | |
	| |<------- Error Response -----| |		| | | Resource | | |
	| | | |		| |--(2)--- Access Resource --->| Server | | |
	| | +----------+ +-------+		| |<------- Resource Response --| (RS) | | |
	| | | GS |		| | | | | |
	| |--(3)--- Refresh AuthZ ------------------->| |		| |--(3)--- Access Resource --->| | | |
			| |<------- Error Response -----| | | |
			| | | | | |
			| | +----------+ | |
			| | | |
			| |--(4)--- Read AuthZ ---------------------->| |
	| |<------- AuthZ Response -------------------| |		| |<------- AuthZ Response -------------------| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Resource Request* The Client accesses the RS with the access		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
			"authorization" object (Section 6.4.3) with a fresh access token.
			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.
	2. *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.
	3. *Refresh AuthZ* If the Client received an AuthZ URI in the		4. *Read AuthZ* The Client makes another Read AuthZ (Section 4.7)
	Response JSON "authorization" object (Section 7.4.3), the Client		with an HTTP GET to the AZ URI and receives an Response JSON
	can Refresh AuthZ (Section 5.6) with an HTTP GET to the AuthZ URI		"authorization" object (Section 6.4.3) with a fresh access token.
	and receive an Response JSON "authorization" object"
	(Section 7.4.3) with a fresh access token.
	3.10. 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 |
			| | | URI | |
			+--------------+-----------+--------+-----------------------------+
	| Read Grant | GET | Grant | wait, or grant |		| Read Grant | GET | Grant | wait, or grant |
	| | | URI | |		| | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Update Grant | PUT | Grant | interaction, wait, or grant |		| Update Grant | PUT | Grant | interaction, wait, or grant |
	| | | URI | |		| | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Delete Grant | DELETE | Grant | success |		| Delete Grant | DELETE | Grant | success |
	| | | URI | |		| | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Refresh | GET | AuthZ | authorization |		| Read AuthZ | GET | AZ URI | authorization |
	| AuthZ | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Update AuthZ | PUT | AuthZ | authorization |		| Update AuthZ | PUT | AZ URI | authorization |
	| | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Delete AuthZ | DELETE | AuthZ | success |		| Delete AuthZ | DELETE | AZ URI | success |
	| | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| GS Options | OPTIONS | GS URI | metadata |		| GS Options | OPTIONS | GS URI | metadata |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Grant | OPTIONS | Grant | metadata |		| Grant | OPTIONS | Grant | metadata |
	| Options | | URI | |		| Options | | URI | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| AuthZ | OPTIONS | AuthZ | metadata |		| AuthZ | OPTIONS | AZ URI | metadata |
	| Options | | URI | |		| Options | | | |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	Table 1		Table 1
	[ Editor: is there value in an API for listing a Client's Grants?		[ Editor: is there value in an API for listing a Client's Grants?
	eg:]		eg:]
	List Grants GET GS URI JSON array of Grant URIs		List Grants GET GS URI JSON array of Grant URIs
	4. Grant and AuthZ Life Cycle		3. Grant and AuthZ Life Cycle
	[Editor: straw man for life cycles.]		[Editor: straw man for life cycles.]
	*Grant life Cycle*		*Grant life Cycle*
	The Client MAY create, read, update, and delete Grants. A Grant		The Client MAY create, read, update, and delete Grants. A Grant
	persists until it has expired, is deleted, or another Grant is		persists until it has expired, is deleted, or another Grant is
	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*
	Authorizations are OPTIONALLY included in a Grant Response
	"authorization" Object (Section 7.4.3), and are represented by an		An Authorization are represented by an AZ URI and are MAY be included
	AuthZ URI. If an AuthZ URI is included, the Client MAY refresh,		in a Grant Response "authorization" Object (Section 6.4.3) or as a
	update, and delete Authorizations.		member of the Grant Response "authorizations" list. If a Client
			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
			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.
	5. GS APIs		4. GS APIs
	*Client Authentication*		*Client Authentication*
	All APIs except for GS Options require the Client to authenticate.		All APIs except for GS Options require the Client to authenticate.
	This document defines the JOSE Authentication mechanism in		This document defines the JOSE Authentication mechanism in
	Section 10. Other mechanisms include [TBD].		Section 10. Other mechanisms include [TBD].
	5.1. Create Grant		4.1. Create Grant
	The Client creates a Grant by doing an HTTP POST of a JSON [RFC8259]		The Client creates a Grant by doing an HTTP POST of a JSON [RFC8259]
	document to the GS URI.		document to the GS URI.
	The JSON document MUST include the following from the Request JSON		The JSON document MUST include the following from the Request JSON
	Section 5.5:		Section 4.6:
	* iat		* iat
	* nonce		* nonce
	* uri set to the GS URI		* uri set to the GS URI
	* client		* client
	and MAY include the following from Request JSON Section 5.5		and MAY include the following from Request JSON Section 4.6
	* user		* user
	* interaction		* interaction
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	* reciprocal		The GS MUST respond with one of Grant Response Section 6.1,
			Interaction Response Section 6.2, Wait Response Section 6.3, or one
	The GS MUST respond with one of Grant Response Section 7.1,
	Interaction Response Section 7.2, Wait Response Section 7.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 to		Following is a non-normative example where the Client wants to
	interact with the User with a popup and is requesting identity claims		interact with the User with a popup and is requesting identity claims
	about the User and read access to the User's contacts:		about the User and read access to the User's contacts:
	skipping to change at page 20, line 28 ¶		skipping to change at page 24, line 28 ¶
	},		},
	"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" : {} } }
	}		}
	5.2. Read Grant		4.2. Verify Grant
			The Client verifies a Grant by doing an HTTP PATCH of a JSON document
			to the corresponding Grant URI.
			The JSON document MUST contain verification.nonce per Section 4.6.7.
			Following is a non-normative example:
			{
			"verification": { "nonce":"55e8a90f-a563-426d-8c35-d6d8ed54afeb" }
			}
			The GS MUST respond with one of Grant Response Section 6.1 or one of
			the following errors:
			* TBD
			from Error Responses Section 9.
			4.3. Read Grant
	The Client reads a Grant by doing an HTTP GET of the corresponding		The Client reads a Grant by doing an HTTP GET of the corresponding
	Grant URI.		Grant URI.
	The GS MUST respond with one of Grant Response Section 7.1,		The GS MUST respond with one of Grant Response Section 6.1, Wait
	Interaction Response Section 7.2, Wait Response Section 7.3, or one		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.
	5.3. Update Grant		4.4. Update Grant
	The Client updates a Grant by doing an HTTP PUT of a JSON document to		The Client updates a Grant by doing an HTTP PUT of a JSON document to
	the corresponding Grant URI.		the corresponding Grant URI.
	The JSON document MUST include the following from the Request JSON		The JSON document MUST include the following from the Request JSON
	Section 5.5		Section 4.6
	* iat		* iat
	* uri set to the Grant URI		* uri set to the Grant URI
	and MAY include the following from Request JSON Section 5.5
			and MAY include the following from Request JSON Section 4.6
	* user		* user
	* interaction		* interaction
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	* reciprocal		The GS MUST respond with one of Grant Response Section 6.1,
			Interaction Response Section 6.2, Wait Response Section 6.3, or one
	The GS MUST respond with one of Grant Response Section 7.1,
	Interaction Response Section 7.2, Wait Response Section 7.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 made an		Following is a non-normative example where the Client made an
	"interaction"."keep":true request, and now wants to update the		interaction.keep:true request, and now wants to update the request
	request with additional claims:		with additional claims:
	Example 3		Example 3
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint/grant/example3",		"uri" : "https://as.example/endpoint/grant/example3",
	"claims": {		"claims": {
	"oidc": {		"oidc": {
	"userinfo" : {		"userinfo" : {
	"email" : { "essential" : true },		"email" : { "essential" : true },
	"name" : { "essential" : true },		"name" : { "essential" : true },
	"picture" : null		"picture" : null
	}		}
	}		}
	}		}
	}		}
	5.4. Delete Grant		4.5. Delete Grant
	The Client deletes a Grant by doing an HTTP DELETE of the		The Client deletes a Grant by doing an HTTP DELETE of the
	corresponding Grant URI.		corresponding Grant URI.
	The GS MUST respond with OK 200, or one of the following errors:		The GS MUST respond with OK 200, or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.5. Request JSON		4.6. Request JSON
	[Editor: do we want to reuse the JWT claims "iat", "jti", etc.? ]		[Editor: do we want to reuse the JWT claims "iat", "jti", etc.? ]
	* *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 5.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 5.3.		URI if in an Update Grant Section 4.4.
	5.5.1. "client" Object		4.6.1. "client" Object
	The client object MUST contain either the id attribute for Registered		The client object MUST contain either the id attribute for Registered
	Clients, or the display object for Dynamic Clients.		Clients, 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 the Registered 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
	[Editor: a max length for the name?] [Editor: a max length for the
	URI?]
	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.
	5.5.2. "interaction" Object		[Editor: a max length for the name and URI so a GS can reserve
			appropriate space?]
			4.6.2. "interaction" Object
	The interaction object contains the type of interaction the Client		The interaction object contains the type of interaction the Client
	will provide the User. Other attributes		will provide the User. Other attributes
	* *keep* - a JSON boolean. If set to the JSON value true, the GS		* *keep* - a JSON boolean. If set to the JSON value true, the GS
	will not transfer the User interaction back to the Client after		will not transfer the User interaction back to the Client after
	processing the Grant request. The JSON value false is equivalent		processing the Grant request. The JSON value false is equivalent
	to the attribute not being present, and the GS will transfer the		to the attribute not being present, and the GS will transfer the
	User interaction back to the Client after processing the request.		User interaction back to the Client after processing the request.
	This attribute is OPTIONAL		This attribute is OPTIONAL
	* *type* - contains one of the following values: "popup",		* *type* - contains one of the following values: "redirect" or
	"redirect", "qrcode", or "code". Details in Section 7.4.7. This		"indirect". Details in Section 7. This attribute is REQUIRED.
	attribute is REQUIRED.
	[Editor: do we want this to be an array of types the Client can		[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? This would only be the case if the GS is not able to
	support all types and negotiation is required. Is that required?]		support all types and negotiation is required. Is that required?]
	* *redirect_uri* - this attribute is REQUIRED if the type is		* *completion_uri* - this attribute is REQUIRED if the type is
	"redirect". It is the URI that the Client requests the GS to		"redirect". It is the URI that the Client requests the GS to
	redirect the User to after the GS has completed interacting with		redirect the User to after the GS has completed interacting with
	the User. If the Client manages session state in URIs, then the		the User. If the Client manages session state in URIs, then the
	redirect_uri SHOULD contain that state.		redirect_uri SHOULD contain that state.
	* *completion_uri* - this attribute is OPTIONAL and is ignored		* *information_uri* - this attribute is OPTIONAL and is ignored
	unless the type is "qrcode" or "code". This is the URI the Client		unless the type is "indirect". This is the URI the Client would
	would like the GS to redirect the User to after the interaction		like the GS to redirect the User to after the interaction with the
	with the User is complete.		User is complete.
	* *ui_locales* - End-User's preferred languages and scripts for the		* *ui_locales* - End-User's preferred languages and scripts for the
	user interface, represented as a space-separated list of [RFC5646]		user interface, represented as a space-separated list of [RFC5646]
	language tag values, ordered by preference. This attribute is		language tag values, ordered by preference. This attribute is
	OPTIONAL.		OPTIONAL.
	[Editor: do we need max pixels or max chars for qrcode interaction?		* *verify* - a boolean value. If set to the JSON value true, the GS
	Either passed to GS, or max specified values here?]		will return a nonce value with the Completion URI.
	[Editor: other possible interaction models could be a "webview",
	where the Client can display a web page, or just a "message", where
	the client can only display a text message]
	[Editor: we may need to include interaction types for iOS and Android
	as the mobile OS APIs evolve.]
	5.5.3. "user" Object		4.6.3. "user" Object
	* *exists* - MUST contain the JSON true value. Indicates the Client		* *exists* - if present, MUST contain the JSON true value.
	requests the GS to return a "user"."exists" value in an		Indicates the Client requests the GS to return a user.exists value
	Interaction Response Section 7.2. This attribute is OPTIONAL, and		in an Interaction Response Section 6.2. This attribute is
	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.
	Contains one or more of the following identifiers for the User:		Contains one or more of the following identifiers for the User:
	- *phone_number* - contains a phone number per Section 5 of		- *phone_number* - contains a phone number per Section 5 of
	[RFC3966].		[RFC3966].
	- *email* - contains an email address per [RFC5322].		- *email* - contains an email address per [RFC5322].
	- *oidc_id_token* - is an OpenID Connect ID Token per [OIDC]		- *oidc* - is an object containing both the "iss" and "sub"
			attributes from an OpenID Connect ID Token [OIDC] Section 2.
			* *claims* - an optional object containing one or more assertions
			the Client has about the User.
			- *oidc_id_token* - an OpenID Connect ID Token per [OIDC]
	Section 2.		Section 2.
	5.5.4. "authorization" Object		* *reciprocal* - indicates this Grant Request or Update is the
			reciprocal of another Grant. Contains the Grant URI of the
			reciprocal Grant.
			4.6.4. "authorization" Object
	* *type* - one of the following values: "oauth_scope" or		* *type* - one of the following values: "oauth_scope" or
	"oauth_rich". This attribute is REQUIRED.		"oauth_rich". 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" 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]
	5.5.5. "authorizations" Object		4.6.5. "authorizations" Object
	A JSON array of "authorization" objects. Only one of "authorization"		A JSON array of "authorization" objects. Only one of "authorization"
	or "authorizations" may be in the Request JSON.		or "authorizations" may be in the Request JSON.
	[Editor: instead of an array, we could have a Client defined		[Editor: instead of an array, we could have a Client defined
	dictionary of "authorization" objects]		dictionary of "authorization" objects]
	5.5.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
	- *id_token* - Claims that will be included in the returned ID		- *id_token* - Claims that will be included in the returned ID
	Token. If the null value, an ID Token will be returned		Token. If the null value, an ID Token will be returned
	skipping to change at page 24, line 49 ¶		skipping to change at page 29, line 30 ¶
	The contents of the userinfo and id_token objects are Claims as		The contents of the userinfo and id_token objects are Claims as
	defined in [OIDC] Section 5.		defined in [OIDC] Section 5.
	* *oidc4ia* - OpenID Connect for Identity Assurance claims request		* *oidc4ia* - OpenID Connect for Identity Assurance claims request
	per [OIDC4IA].		per [OIDC4IA].
	* *vc* - [Editor: define how W3C Verifiable Credentials [W3C_VC] can		* *vc* - [Editor: define how W3C Verifiable Credentials [W3C_VC] can
	be requested.]		be requested.]
	5.5.7. "reciprocal" Object		4.6.7. "verification" Object
	* *uri* - the Grant URI for the Reciprocal Grant. This attribute is
	REQUIRED.
	* *client* - the client object must contain the "id" attribute with
	the Client ID the Grant was issued to. This attribute is
	REQUIRED.
	* *authorization* - an authorization object per Section 7.4.3 in the
	Response JSON.
	* *authorizations* - an authorizations object per Section 7.4.4 in		The verification Object is used with the Verify Grant Section 4.2.
	the Response JSON.
	* *claims* - a claims object per Section 7.4.5 in the Response JSON.		* *nonce* the Interaction Nonce received from the GS via the
			Completion URI. This attribute MUST only be used in the Verify
			Grant Section 4.2.
	[Editor: parameters for the Client to request it wants the Grant		[Editor: parameters for the Client to request it wants the Grant
	Response signed and/or encrypted?]		Response signed and/or encrypted?]
	5.6. Refresh Authorization		4.7. Read Authorization
	The Client updates an Authorization by doing an HTTP GET to the		The Client acquires an Authorization by doing an HTTP GET to the
	corresponding AuthZ URI.		corresponding AZ URI.
	The GS MUST respond with an Response JSON "authorization" object		The GS MUST respond with a Authorization JSON document Section 6.5,
	Section 7.4.3, or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.7. Update Authorization		4.8. Update Authorization
	The Client updates an Authorization by doing an HTTP PUT to the		The Client updates an Authorization by doing an HTTP PUT to the
	corresponding AuthZ URI of the following JSON. All of the following		corresponding AZ URI of the following JSON. All of the following
	MUST be included.		MUST be included.
	* *iat* - the time of the response as a NumericDate.		* *iat* - the time of the response as a NumericDate.
	* *uri* - the AuthZ URI.		* *uri* - the AZ URI.
	* *authorization* - the new authorization requested per the Request		* *authorization* - the new authorization requested per the Request
	JSON "authorization" object Section 5.5.4.		JSON "authorization" object Section 4.6.4.
	The GS MUST respond with an Response JSON "authorization" object		The GS MUST respond with a Authorization JSON document Section 6.5,
	Section 7.4.3, or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.8. Delete Authorization		4.9. Delete Authorization
	The Client deletes an Authorization by doing an HTTP DELETE to the		The Client deletes an Authorization by doing an HTTP DELETE to the
	corresponding AuthZ URI.		corresponding AZ URI.
	The GS MUST respond with OK 200, or one of the following errors:		The GS MUST respond with OK 200, or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.9. GS Options		4.10. GS Options
	The Client can get the metadata for the GS by doing an HTTP OPTIONS		The Client can get the metadata for the GS by doing an HTTP OPTIONS
	of the corresponding GS URI. This is the only API where the GS MAY		of the corresponding GS URI. This is the only API where the GS MAY
	respond to an unauthenticated request.		respond to an unauthenticated request.
	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.
	skipping to change at page 26, line 50 ¶		skipping to change at page 31, line 21 ¶
	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		- *user_exists* - boolean indicating if user.exists is supported.
	supported.
	- *authorizations* - boolean indicating if a request for multiple		- *authorizations* - boolean indicating if a request for multiple
	authorizations is supported.		authorizations 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
	from Error Responses Section 9.		from Error Responses Section 9.
	5.10. Grant Options		4.11. Grant Options
	The Client can get the metadata for the Grant by doing an HTTP		The Client can get the metadata for the Grant by doing an HTTP
	OPTIONS of the corresponding Grant URI.		OPTIONS of the corresponding Grant URI.
	The GS MUST respond with the the following JSON document:		The GS MUST respond with the the following JSON document:
	* *verbs* - an array of the HTTP verbs supported at the GS URI.		* *verbs* - an array of the HTTP verbs supported at the GS URI.
	or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.11. AuthZ Options		4.12. AuthZ Options
	The Client can get the metadata for the AuthZ by doing an HTTP		The Client can get the metadata for the AuthZ by doing an HTTP
	OPTIONS of the corresponding AuthZ URI.		OPTIONS of the corresponding AZ URI.
	The GS MUST respond with the the following JSON document:		The GS MUST respond with the the following JSON document:
	* *verbs* - an array of the HTTP verbs supported at the GS URI.		* *verbs* - an array of the HTTP verbs supported at the GS URI.
	or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	5.12. Request Verification		4.13. Request Verification
	On receipt of a request, the GS MUST verify the following:		On receipt of a request, the GS MUST verify the following:
	* TBD		* TBD
	6. GS Initiated Grant		5. GS Initiated Grant
	[Editor: In OAuth 2.0, all flows are initiated at the Client. If the		[Editor: In OAuth 2.0, all flows are initiated at the Client. If the
	AS wanted to initiate a flow, it redirected to the Client, that		AS wanted to initiate a flow, it redirected to the Client, that
	redirected back to the AS to initiate a flow.		redirected back to the AS to initiate a flow.
	Here is a proposal to support GS initiated: authentication; just-in-		Here is a proposal to support GS initiated: authentication; just-in-
	time (JIT) provisioning; and authorization]		time (JIT) provisioning; and authorization]
	*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 3.3 for the sequence diagram.		See Section 2.5 for the sequence diagram.
	7. GS API Responses		6. GS API Responses
	7.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 7.4		Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* expires_in		* expires_in
	and MAY include the following from the Response JSON Section 7.4		and MAY include the following from the Response JSON Section 6.4
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	* reciprocal
	Example non-normative Grant Response JSON document for Example 1 in		Example non-normative Grant Response JSON document for Example 1 in
	Section 3.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",
	"scope" : "read_contacts",		"scope" : "read_contacts",
	"expires_in" : 3600,		"expires_in" : 3600,
	skipping to change at page 29, line 29 ¶		skipping to change at page 33, line 43 ¶
	"id_token" : "eyJhbUzI1N.example.id.token.YRw5DFdbW",		"id_token" : "eyJhbUzI1N.example.id.token.YRw5DFdbW",
	"userinfo" : {		"userinfo" : {
	"name" : "John Doe",		"name" : "John Doe",
	"picture" : "https://photos.example/p/eyJzdkiO"		"picture" : "https://photos.example/p/eyJzdkiO"
	}		}
	}		}
	}		}
	}		}
	Example non-normative Grant Response JSON document for Example 2 in		Example non-normative Grant Response JSON document for Example 2 in
	Section 3.1:		Section 4.1:
	{		{
	"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": {		"authorization": {
	"type" : "oauth_scope",		"uri" : "https://as.example/endpoint/authz/example2"
	"scope" : "read_calendar write_calendar",
	"expires_in" : 3600,
	"mechanism" : "jose",
	"token" : "eyJJ2D6.example.access.token.mZf9p"
	"certificate": {
	"x5u" : "https://as.example/cert/example2"
	},
	"uri" : "https://as.example/endpoint/authz/example2"
	}		}
	}		}
	7.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 7.4		JSON Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* interaction		* interaction
	and MAY include the following from the Response JSON Section 7.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" : "popup",		"type" : "popup",
	"authorization_uri" : "https://as.example/popup/example4"		"authorization_uri" : "https://as.example/popup/example4"
	},		},
	"user": {		"user": {
	"exists" : true		"exists" : true
	}		}
	}		}
	7.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 7.4		Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* wait		* wait
	A non-normative example of Wait Response follows:		A non-normative example of Wait Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example5",		"uri" : "https://as.example/endpoint/grant/example5",
	"wait" : 300		"wait" : 300
	}		}
	7.4. Response JSON		6.4. Response JSON
	Details of the JSON document:		Details of the JSON document:
	* *iat* - the time of the response as a NumericDate.		* *iat* - the time of the response as a NumericDate.
	* *nonce* - the nonce that was included in the Request JSON		* *nonce* - the nonce that was included in the Request JSON
	Section 5.5.		Section 4.6.
	* *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.
	7.4.1. "interaction" Object		6.4.1. "interaction" Object
	If the GS wants the Client to start the interaction, the GS MUST		If the GS wants the Client to start the interaction, the GS MUST
	return the interaction mechanism provided by the Client in the Grant		return the interaction mechanism provided by the Client in the Grant
	Request, and include the required attributes in the interaction		Request, and include the required attributes in the interaction
	object:		object:
	* *type* - this MUST match the type provided by the Client in the		* *type* - this MUST match the type provided by the Client in the
	Grant Request client.interaction object.		Grant Request client.interaction object.
	* *authorization_uri* - the URI to redirect the user to or load in		* *authorization_uri* - the URI to redirect the user to or load in
	the popup. Must be included if type is "popup" and "redirect"		the popup. Must be included if type is "redirect"
	* *display_uri* - the URI to be displayed to the User for them to		* *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		navigate to and enter the code. Must be included if type is
	"qrcode" and "code"		"indirect"
	* *qr_uri* - the URI to show as a QR code. MUST be included if type
	is "qrcode"
	* *user_code* - a text string of the code to display to the User.		* *user_code* - a text string of the code to display to the User.
	Must be included if type is "qrcode" or "code".		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		[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		so that a device knows the maximum it needs to support? A smart
	device may have limited screen real estate.]		device may have limited screen real estate.]
	The authorization_uri, qr_uri, and user_code MUST be unique and only		The authorization_uri, qr_uri, and user_code MUST be unique and only
	match the associated Grant URI.		match the associated Grant URI.
	TBD: entropy and other security considerations for the		TBD: entropy and other security considerations for the
	authorization_uri, qr_uri, and the user_code.		authorization_uri, qr_uri, and the user_code.
	See Interaction Types Section 7.4.7 for details.		See Interaction Types Section 7 for details.
	7.4.2. "user" Object		6.4.2. "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 5.5.3		user.identifiers object Section 4.6.3
	7.4.3. "authorization" Object		6.4.3. "authorization" Object
	The "authorization" object is a response to the Request		The Response JSON authorization object is a subset of the
	"authorization" object Section 5.5.4, the Refresh Authorization		Authorization JSON Section 6.5. It contains only the AZ URI if the
	Section 5.6, or the Update Authorization Section 5.7.		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
			A JSON array of authorization objects. Support for the
			authorizations object is OPTIONAL.
			6.4.5. "claims" Object
			The claims object is a response to the Request "claims" object
			Section 4.6.4.
			* *oidc*
			- *id_token* - an OpenID Connect ID Token containing the Claims
			the User consented to be released.
			- *userinfo* - the Claims the User consented to be released.
			Claims are defined in [OIDC] Section 5.
			* *oidc4ia* - OpenID Connect for Identity Assurance claims response
			per [OIDC4IA].
			* *vc*
			The verified claims the user consented to be released. [Editor:
			details TBD]
			6.5. Authorization JSON
			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
			in the "authorization" object Section 4.6.4 and "authorizations" list
			members Section 6.4.4.
	* *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 5.5.4 for details.		See the "type" object in Section 4.6.4 for details.
	* *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.
	skipping to change at page 33, line 5 ¶		skipping to change at page 37, line 50 ¶
	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 AuthZ URI. Used to refresh, update, and delete the		* *uri* - the AZ URI. Used to get, update, and delete the
	authorization. This attribute is OPTIONAL.		authorization. This will be the same URI that was used in a Read
			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: any value in an expiry for the Authorization?]
	7.4.4. "authorizations" Object		The following is a non-normative example of an Authorization JSON
			document:
	A JSON array of authorization objects. Support for the		{
	authorizations object is OPTIONAL.		"type" : "oauth_scope",
			"scope" : "read_calendar write_calendar",
			"mechanism" : "jose",
			"token" : "eyJJ2D6.example.access.token.mZf9p"
			"expires_in" : 3600,
			"certificate": {
			"x5u" : "https://as.example/cert/example2"
			},
			"uri" : "https://as.example/endpoint/authz/example2"
			}
	7.4.5. "claims" Object		6.5.1. Signing and Encryption
	The claims object is a response to the Request "claims" object		[Editor: TBD - how response is signed and/or encrypted by the GS. Is
	Section 5.5.4.		there a generalized description, or is it mechanism specific?]
	* *oidc*		6.6. Response Verification
	- *id_token* - an OpenID Connect ID Token containing the Claims		On receipt of a response, the Client MUST verify the following:
	the User consented to be released.
	- *userinfo* - the Claims the User consented to be released.		* TBD
	Claims are defined in [OIDC] Section 5.		7. Interactions
	* *oidc4ia* - OpenID Connect for Identity Assurance claims response		There are two types of interactions that a Client can initiate with a
	per [OIDC4IA].		GS: redirect and indirect. Extensions may define additional
			interaction types.
	* *vc*		7.1. Redirect Interaction
	The verified claims the user consented to be released. [Editor:		A Redirect Interaction is characterized by the GS returning the User
	details TBD]		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:
	7.4.6. "reciprocal" Object		1. If not interaction.verify, the Client creates a unique
			Completion URI.
	The following MUST be included		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.
	* *nonce* - a unique identifier for this request. Note the Grant		3. The GS creates a Grant with a unique Grant URI and Authorization
	Response MUST contain a matching nonce attribute value.		URI and binds them to the Completion URI.
	* *client*		4. The GS creates an Interaction Response setting interaction.type
			to "redirect" and interaction.authorization_uri to the
			Authorization URI and returns it to the Client.
	- *id* - the Client ID making the request		5. If not interaction.verify, the Client creates and sets a a
			unique completion browser cookie and binds it to the completion
			URI. The cookie MUST not be able to be used to derive the
			Completion URI.
	One or more of the following objects from the Request JSON		6. The Client redirects the User's browser to the Authorization URI
	Section 5.5 are included:		using any available browser redirect mechanism.
	* *authorization* Section 7.4.3		7. The GS locates the Grant bound to the Authorization URI.
	* *authorizations* Section 7.4.4
	* *claims* Section 7.4.5		8. The GS interacts with the User.
	7.4.7. Interaction Types		9. If interaction.verify, the GS creates an Interaction Nonce,
			binds it to the Grant, and appends it to the Completion URI as
			the "nonce" query parameter.
	If the GS wants the Client to initiate the interaction with the User,		10. The GS redirects the User's browser to the Completion URI using
	then the GS will return an Interaction Response. The Client will		any available browser redirect mechanism.
	initiate the interaction with the User in one of the following ways:
	* *popup* The Client will create a new popup child browser window		11. If not interaction.verify, the Client confirms the completion
	with URI contained in the "interaction"."authorization_uri"		browser cookie is bound to the Completion URI.
	attribute. [Editor: more details on how to do this] The GS will
	close the popup window when the interactions with the User are
	complete. [Editor: confirm GS can stll do this on all browsers,
	or does Client need to close? If so, then Client needs to provide
	a redirect_uri.]
	* *redirect* The Client will redirect the User to the		12. If interaction.verify, the Client makes a Verify Grant call with
	"interaction"."authorization_uri" attribute. When the GS		the Interaction Nonce, and the Grant.
	interactions with the User are complete, the GS will redirect the
	User to the "interaction"."redirect_uri" attribute the Client
	provided in the Grant Request.
	* *qrcode* The Client will create a [QR_Code] of the		A GS MUST support the Redirect Interaction type.
	"interaction"."qr" attribute and display the resulting graphic.
	The Client will also display the "interaction"."display_uri" and
	"interaction"."user_code" per the "code" type.
	* *code* The Client will display the "interaction"."user_code"		7.2. Indirect Interaction
	contents and direct the User to navigate to the
	"interaction"."display_uri" value and enter the code.
	A GS MUST support the "popup", "redirect", "qrcode", and "code"		An Indirect Interaction is characterized by the GS not being able to
	interaction types.		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.
	[Editor: is this too restrictive?]		1. Generation
	7.4.8. Signing and Encryption		1. The GS generates a Short URI and User Code unique to the
			Grant.
	[Editor: TBD - how response is signed and/or encrypted by the GS. Is		2. The GS sends the Short URI, Code URI, and User Code to the
	there a generalized description, or is it mechanism specific?]		Client.
	7.5. Response Verification		2. Display
	On receipt of a response, the Client MUST verify the following:		1. If possible, the Client MAY display the Short URI to the User
			as a scannable code such as a [QR_Code]. The User MAY then
			scan the image that will open the Short URI on the User's
			scanning device.
	* TBD		2. The Client MAY optionally launch a system browser to open the
			Short URI.
			3. The Client MUST display the User Code and instructions to
			enter it at the Code URI. The User MAY navigate a browser on
			a separate device to the Code URI.
			If the User arrived at the GS via the Short URI, the GS will use the
			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
			authenticate the User, and then prompt the User to enter the User
			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
			as the mobile OS APIs evolve.]
	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 7.4.3.		authorization.mechanism attribute Section 6.4.3.
	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 35, line 47 ¶		skipping to change at page 41, line 39 ¶
	Other documents that specify other Client authentication mechanisms		Other documents that specify other Client authentication mechanisms
	will replace this section.		will replace this section.
	In the JOSE Authentication Mechanism, the Client authenticates by		In the JOSE Authentication Mechanism, the Client authenticates by
	using its private key to sign a JSON document with JWS per [RFC7515]		using its private key to sign a JSON document with JWS per [RFC7515]
	which results in a token using JOSE compact serialization.		which results in a token using JOSE compact serialization.
	[Editor: are there advantages to using JSON serialization in the		[Editor: are there advantages to using JSON serialization in the
	body?]		body?]
	Different instances of a Registered Clients MAY have different		Different instances of a Registered Client MAY have different private
	private keys, but certificates bind them to a public key the GS has		keys, but each instance has a certificate to bind its private key to
	for the Client ID. An instance of a Client will use the same private		to a public key the GS has for the Client ID. An instance of a
	key for all signing.		Client will use the same private key for all signing operations.
	The Client and the GS MUST both use HTTP/2 ([RFC7540]) or later, and		The Client and the GS MUST both use HTTP/2 ([RFC7540]) or later, and
	TLS 1.3 ([RFC8446]) or later, when communicating with each other.		TLS 1.3 ([RFC8446]) or later, when communicating with each other.
	[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]		[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]
	The token may be included in an HTTP header, or as the HTTP message		The token may be included in an HTTP header, or as the HTTP message
	body.		body.
	The following sections specify how the Client uses JOSE to		The following sections specify how the Client uses JOSE to
	skipping to change at page 36, line 27 ¶		skipping to change at page 42, line 19 ¶
	The Client authenticates to the GS by passing either a signed header		The Client authenticates to the GS by passing either a signed header
	parameter, or a signed message body. The following table shows the		parameter, or a signed message body. The following table shows the
	verb, uri and token location for each Client request to the GS:		verb, uri and token location for each Client request to the GS:
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| request | http verb | uri | token in |		| request | http verb | uri | token in |
	+===============+===========+===========+==========+		+===============+===========+===========+==========+
	| Create Grant | POST | GS URI | body |		| Create Grant | POST | GS URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
			| Verify Grant | PATCH | Grant URI | body |
			+---------------+-----------+-----------+----------+
	| Read Grant | GET | Grant URI | header |		| Read Grant | GET | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Update Grant | PUT | Grant URI | body |		| Update Grant | PUT | Grant URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Delete Grant | DELETE | Grant URI | success |		| Delete Grant | DELETE | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Refresh AuthZ | GET | AuthZ URI | body |		| Read AuthZ | GET | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Update AuthZ | PUT | AuthZ URI | body |		| Update AuthZ | PUT | AZ URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Delete AuthZ | DELETE | AuthZ URI | header |		| Delete AuthZ | DELETE | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| GS Options | OPTIONS | GS URI | header |		| GS Options | OPTIONS | GS URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| Grant Options | OPTIONS | Grant URI | header |		| Grant Options | OPTIONS | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	| AuthZ Options | OPTIONS | AuthZ URI | header |		| AuthZ Options | OPTIONS | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-----------+-----------+----------+
	Table 2		Table 2
	10.1.1. Authorization Header		10.1.1. Authorization Header
	For requests with the token in the header, the JWS payload MUST		For requests with the token in the header, the JWS payload MUST
	contain the following attributes:		contain the following attributes:
	*iat* - the time the token was created as a NumericDate.		*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section		*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.		4.1.7.
	*uri* - the value of the URI being called (GS URI, Grant URI, or		*uri* - the value of the URI being called (GS URI, Grant URI, or AZ
	AuthZ URI).		URI).
	*verb* - the HTTP verb being used in the call ("GET", "DELETE",		*verb* - the HTTP verb being used in the call ("GET", "DELETE",
	"OPTIONS")		"OPTIONS")
	The HTTP authorization header is set to the "jose" parameter followed		The HTTP authorization header is set to the "jose" parameter followed
	by one or more white space characters, followed by the resulting		by one or more white space characters, followed by the resulting
	token.		token.
	A non-normative example of a JWS payload and the HTTP request		A non-normative example of a JWS payload and the HTTP request
	follows:		follows:
	skipping to change at page 42, line 10 ¶		skipping to change at page 48, line 10 ¶
	The RS has a public key for the GS that it uses to verify the		The RS has a public key for the GS that it uses to verify the
	certificate or certificate chain the Client includes in the JWS		certificate or certificate chain the Client includes in the JWS
	header.		header.
	10.3. Request Encryption		10.3. Request Encryption
	[Editor: to be fleshed out]		[Editor: to be fleshed out]
	The Client encrypts a request when ??? using the GS public key		The Client encrypts a request when ??? using the GS public key
	returned as the ??? attribute in GS Options Section 5.9.		returned as the ??? attribute in GS Options Section 4.10.
	10.4. Response Signing		10.4. Response Signing
	[Editor: to be fleshed out]		[Editor: to be fleshed out]
	The Client verifies a signed response ??? using the GS public key		The Client verifies a signed response ??? using the GS public key
	returned as the ??? attribute in GS Options Section 5.9.		returned as the ??? attribute in GS Options Section 4.10.
	10.5. Response Encryption		10.5. Response Encryption
	[Editor: to be fleshed out]		[Editor: to be fleshed out]
	The Client decrypts a response when ??? using the private key		The Client decrypts a response when ??? using the private key
	matching the public key included in the request as the ??? attribute		matching the public key included in the request as the ??? attribute
	in Section 5.5.		in Section 4.6.
	11. Extensibility		11. Extensibility
	This standard can be extended in a number of areas:		This standard can be extended in a number of areas:
	* *Client Authentication Mechanisms*		* *Client Authentication Mechanisms*
	- An extension could define other mechanisms for the Client to		- An extension could define other mechanisms for the Client to
	authenticate to the GS and/or RS such as Mutual TLS or HTTP		authenticate to the GS and/or RS such as Mutual TLS or HTTP
	Signing. Constrained environments could use CBOR [RFC7049]		Signing. Constrained environments could use CBOR [RFC7049]
	skipping to change at page 44, line 35 ¶		skipping to change at page 50, line 35 ¶
	authenticate to the GS and a resource?*		authenticate to the GS and a resource?*
	Both Registered Clients and Dynamic Clients can have a private		Both Registered Clients and Dynamic Clients can have a private
	key, eliminating the public Client issues in OAuth 2.0, as a		key, eliminating the public Client issues in OAuth 2.0, as a
	Dynamic Client can create an ephemeral key pair. Using		Dynamic Client can create an ephemeral key pair. Using
	asymetric cryptography also allows each instance of a Registered		asymetric cryptography also allows each instance of a Registered
	Client to have its own private key if it can obtain a		Client to have its own private key if it can obtain a
	certificate binding its public key to the public key the GS has		certificate binding its public key to the public key the GS has
	for the Client. Signed tokens can be passed to downstream		for the Client. Signed tokens can be passed to downstream
	components in a GS or RS to enable independent verification of		components in a GS or RS to enable independent verification of
	the Client and its request. The GS Initiated Sequence Section 6		the Client and its request. The GS Initiated Sequence Section 5
	requires a URL safe parameter, and JOSE is URL safe.		requires a URL safe parameter, and JOSE is URL safe.
	5. *Why does the GS not return parameters to the Client in the		5. *Why does the GS not return parameters to the Client in the
	redirect url?*		redirect url?*
	Passing parameters via a browser redirection is the source of		Passing parameters via a browser redirection is the source of
	many of the security risks in OAuth 2.0. It also presents a		many of the security risks in OAuth 2.0. It also presents a
	challenge for smart devices. In this protocol, the redirection		challenge for smart devices. In this protocol, the redirection
	from the Client to the GS is to enable the GS to interact with		from the Client to the GS is to enable the GS to interact with
	the User, and the redirection back to the Client is to hand back		the User, and the redirection back to the Client is to hand back
	skipping to change at page 46, line 13 ¶		skipping to change at page 52, line 13 ¶
	and a convoluted extension.		and a convoluted extension.
	11. *Why is the "iss" included in the "oidc" identifier object?		11. *Why is the "iss" included in the "oidc" identifier object?
	Would the "sub" not be enough for the GS to identify the User?*		Would the "sub" not be enough for the GS to identify the User?*
	This decouples the GS from the OpenID Provider (OP). The GS		This decouples the GS from the OpenID Provider (OP). The GS
	identifier is the GS URI, which is the endpoint at the GS. The		identifier is the GS URI, which is the endpoint at the GS. The
	OP issuer identifier will likely not be the same as the GS URI.		OP issuer identifier will likely not be the same as the GS URI.
	The GS may also provide claims from multiple OPs.		The GS may also provide claims from multiple OPs.
	12. *Why complicate things with "interaction"."keep"?*		12. *Why complicate things with interaction.keep?*
	The common sequence has a back and forth between the Client and		The common sequence has a back and forth between the Client and
	the GS, and the Client can update the Grant and have a new		the GS, and the Client can update the Grant and have a new
	interaction. Keeping the interaction provides a more seamless		interaction. Keeping the interaction provides a more seamless
	user experience where the results from the first request		user experience where the results from the first request
	determine subsequent requests. For example, a common pattern is		determine subsequent requests. For example, a common pattern is
	to use a GS to authenticate the User at the Client, and to		to use a GS to authenticate the User at the Client, and to
	register the User at the Client using additional claims from the		register the User at the Client using additional claims from the
	GS. The Client does not know a priori if the User is a new		GS. The Client does not know a priori if the User is a new
	User, or a returning User. Asking a returning User to consent		User, or a returning User. Asking a returning User to consent
	skipping to change at page 47, line 7 ¶		skipping to change at page 53, line 7 ¶
	There are numerous use cases where the RS wants non-repudiation		There are numerous use cases where the RS wants non-repudiation
	and providence of the contents of an API call. For example, the		and providence of the contents of an API call. For example, the
	UGS Service Supplier Framework for Authentication and		UGS Service Supplier Framework for Authentication and
	Authorization [UTM].		Authorization [UTM].
	14. *Why use URIs to instead of handles for the Grant and		14. *Why use URIs to instead of handles for the Grant and
	Authorization?*		Authorization?*
	A URI is an identifier just like a handle that can contain GS		A URI is an identifier just like a handle that can contain GS
	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		manipulate a Grant or an Authorization. As the Grant URI and AZ
	AuthZ URI are defined to start with the GS URI, the Client (and		URI are defined to start with the GS URI, the Client (and GS)
	GS) can easily determine which GS a Grant or Authorization		can easily determine which GS a Grant or Authorization belong
	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 AuthZ		16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*
	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 list explicit interactions, instead of the Client and GS		17. *Why list explicit interactions, instead of the Client and GS
	negotiating interaction capabilities?*		negotiating interaction capabilities?*
	The Client knows what interactions it is capable of, and		The Client knows what interactions it is capable of, and
	prefers. Telling the GS the interaction allows the GS to know		prefers. Telling the GS the interaction allows the GS to know
	skipping to change at page 48, line 22 ¶		skipping to change at page 54, line 22 ¶
	TBD		TBD
	15. Security Considerations		15. Security Considerations
	TBD		TBD
	16. References		16. References
	16.1. Normative References		16.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",		[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
	RFC 3966, DOI 10.17487/RFC3966, December 2004,		RFC 3966, DOI 10.17487/RFC3966, December 2004,
	<https://www.rfc-editor.org/info/rfc3966>.		<https://www.rfc-editor.org/info/rfc3966>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<https://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
			[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
			FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
			<https://www.rfc-editor.org/info/rfc4949>.
	[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying		[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
	Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,		Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
	September 2009, <https://www.rfc-editor.org/info/rfc5646>.		September 2009, <https://www.rfc-editor.org/info/rfc5646>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	skipping to change at page 51, line 36 ¶		skipping to change at page 57, line 44 ¶
	* fixed RO definition		* fixed RO definition
	* improved language in Rationals		* improved language in Rationals
	* added user code interaction method, and aligned qrcode interaction		* added user code interaction method, and aligned qrcode interaction
	method		method
	* added completion_uri for code flows		* added completion_uri for code flows
	A.5. draft-hardt-xauth-protocol-03		A.5. draft-hardt-xauth-protocol-04
	* renamed interaction uris to have purpose specific names		* renamed interaction uris to have purpose specific names
			A.6. draft-hardt-xauth-protocol-05
			* separated claims from identifiers in request user object
			* simplified reciprocal grant flow
			* reduced interactions to redirect and indirect
			* simplified interaction parameters
			* added in language for Client to verify interaction completion
			* added Verify Grant API and Interaction Nonce
			* replaced Refresh AuthZ with Read AuthZ. Read and refresh are same
			operation.
	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 uses a private key to authenticate in this protocol		* The Client allows uses a private key to authenticate in this
	instead of the client secret in OAuth 2.0 and OpenID Connect.		protocol instead of the client secret in OAuth 2.0 and OpenID
			Connect.
	* The Client initiates the protocol by making a signed request		* The Client initiates the protocol by making a signed request
	directly to the GS instead of redirecting the User to the GS.		directly to the GS instead of redirecting the User to the GS.
	* The Client does not pass any parameters in redirecting the User to		* The Client does not pass any parameters in redirecting the User to
	the GS, nor receive any parameters in the redirection back from		the GS, and optionally only receives an interaction nonce in the
	the GS.		redirection back from the GS.
	* The refresh_token has been replaced with a AuthZ URI that both		* The refresh_token has been replaced with a AZ URI that both
	represents the access, and is the URI to call to refresh access.		represents the authorization, and is the URI for obtaining a fresh
			access token.
	* The Client can request identity claims to be returned independent		* The Client can request identity claims to be returned independent
	of the ID Token. There is no UserInfo endpoint to query claims as		of the ID Token. There is no UserInfo endpoint to query claims as
	there is in OpenID Connect.		there is in OpenID Connect.
	* The GS URI is the token endpoint. CHECK!!!s		* The GS URI is the token endpoint.
	*Preserved Features*		*Preserved Features*
	* This protocol reuses the OAuth 2.0 scopes, Client IDs, and access		* This protocol reuses the OAuth 2.0 scopes, Client IDs, and access
	tokens of OAuth 2.0.		tokens of OAuth 2.0.
	* This protocol reuses the Client IDs, Claims and ID Token of OpenID		* This protocol reuses the Client IDs, Claims and ID Token of OpenID
	Connect.		Connect.
	* No change is required by the Client or the RS for existing bearer		* No change is required by the Client or the RS for accessing
	token protected APIs.		existing bearer token protected APIs.
	*New Features*		*New Features*
	* A Grant represents the user identity claims and RS access granted		* A Grant represents both the user identity claims and RS access
	to the Client.		granted to the Client.
	* The Client can update, retrieve, and delete a Grant.		* The Client can verify, update, retrieve, and delete a Grant.
	* The GS can initiate a flow by creating a Grant and redirecting the		* The GS can initiate a flow by creating a Grant and redirecting the
	User to the Client with the Grant URI.		User to the Client with the Grant URI.
	* The Client can discovery if an GS has a User with an identifier		* The Client can discovery if a GS has a User with an identifier
	before the GS interacts with the User.		before the GS interacts with the User.
	* The Client can request the GS to first authenticate the User and		* The Client can request the GS to first authenticate the User and
	return User identity claims, and then the Client can update Grant		return User identity claims, and then the Client can update Grant
	request based on the User identity.		request based on the User identity.
	* Support for QR Code initiated interactions.		* Support for scannable code initiated interactions.
	* Each Client instance can have its own private / public key pair.		* Each Client instance can have its own private / public key pair.
	* More Extensibility dimensions.		* Highly extensible per Section 11.
	Appendix C. Open Questions
	Author's Address		Author's Address
	Dick Hardt (editor)		Dick Hardt (editor)
	SignIn.Org		SignIn.Org
	United States		United States
	Email: dick.hardt@gmail.com		Email: dick.hardt@gmail.com
End of changes. 239 change blocks.
	513 lines changed or deleted		757 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/