< draft-hardt-xauth-protocol-07.txt		draft-hardt-xauth-protocol-08.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 6 June 2020		Intended status: Standards Track 6 June 2020
	Expires: 8 December 2020		Expires: 8 December 2020
	The Grant Negotiation and Authorization Protocol		The Grant Negotiation and Authorization Protocol
	draft-hardt-xauth-protocol-07		draft-hardt-xauth-protocol-08
	Abstract		Abstract
	Client software often desires resources or identity claims that are		Client software often desires resources or identity claims that are
	independent of the client. This protocol allows a user and/or		independent of the client. This protocol allows a user and/or
	resource owner to delegate resource authorization and/or release of		resource owner to delegate resource authorization and/or release of
	identity claims to a server. Client software can then request access		identity claims to a server. Client software can then request access
	to resources and/or identity claims by calling the server. The		to resources and/or identity claims by calling the server. The
	server acquires consent and authorization from the user and/or		server acquires consent and authorization from the user and/or
	resource owner if required, and then returns to the client software		resource owner if required, and then returns to the client software
	the authorization and identity claims that were approved. This		the authorization and identity claims that were approved. This
	protocol can be extended to support alternative authorizations,		protocol may be extended to support alternative authorizations,
	claims, interactions, and client authentication mechanisms.		claims, interactions, and client authentication mechanisms.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.4. Notational Conventions . . . . . . . . . . . . . . . . . 7		1.4. Notational Conventions . . . . . . . . . . . . . . . . . 6
	2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Create and Verify Grant . . . . . . . . . . . . . . . . . 8		2.1. "redirect" Interaction . . . . . . . . . . . . . . . . . 7
	2.2. Create and Read Grant - Redirect . . . . . . . . . . . . 9		2.2. "user_code" Interaction . . . . . . . . . . . . . . . . . 8
	2.3. Create and Read Grant - Indirect . . . . . . . . . . . . 10		2.3. Independent RO Authorization . . . . . . . . . . . . . . 10
	2.4. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 11		2.4. Resource Server Access . . . . . . . . . . . . . . . . . 11
	2.5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 12		3. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.6. Create and Update . . . . . . . . . . . . . . . . . . . . 12		3.1. GS API Table . . . . . . . . . . . . . . . . . . . . . . 12
	2.7. Create and Delete . . . . . . . . . . . . . . . . . . . . 14		3.2. Create Grant . . . . . . . . . . . . . . . . . . . . . . 12
	2.8. Create, Discover, and Delete . . . . . . . . . . . . . . 16		3.3. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 14
	2.9. Create and Wait . . . . . . . . . . . . . . . . . . . . . 16		3.4. Request JSON . . . . . . . . . . . . . . . . . . . . . . 14
	2.10. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 17		3.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 14
	2.11. Resource Server Access . . . . . . . . . . . . . . . . . 18		3.4.2. "interaction" Object . . . . . . . . . . . . . . . . 15
	2.12. GS API Table . . . . . . . . . . . . . . . . . . . . . . 19		3.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 15
	3. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 19		3.4.4. "authorization" Object . . . . . . . . . . . . . . . 16
	4. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		3.4.5. "authorizations" Object . . . . . . . . . . . . . . . 16
	4.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 20		3.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 16
	4.2. Verify Grant . . . . . . . . . . . . . . . . . . . . . . 23		3.5. Read Authorization . . . . . . . . . . . . . . . . . . . 17
	4.3. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 24		3.6. GS Options . . . . . . . . . . . . . . . . . . . . . . . 17
	4.4. Update Grant . . . . . . . . . . . . . . . . . . . . . . 24		4. GS Responses . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.5. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 25		4.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 18
	4.6. Request JSON . . . . . . . . . . . . . . . . . . . . . . 25		4.2. Interaction Response . . . . . . . . . . . . . . . . . . 19
	4.6.1. "client" Object . . . . . . . . . . . . . . . . . . . 25		4.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 20
	4.6.2. "interaction" Object . . . . . . . . . . . . . . . . 26		4.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 21
	4.6.3. "user" Object . . . . . . . . . . . . . . . . . . . . 26		4.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 21
	4.6.4. "authorization" Object . . . . . . . . . . . . . . . 27		4.4.2. "interaction" Object . . . . . . . . . . . . . . . . 21
	4.6.5. "authorizations" Object . . . . . . . . . . . . . . . 27		4.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 21
	4.6.6. "claims" Object . . . . . . . . . . . . . . . . . . . 27		4.4.4. "authorization" Object . . . . . . . . . . . . . . . 21
	4.6.7. "verification" Object . . . . . . . . . . . . . . . . 28		4.4.5. "authorizations" Object . . . . . . . . . . . . . . . 22
	4.7. Read Authorization . . . . . . . . . . . . . . . . . . . 28		4.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 22
	4.8. Update Authorization . . . . . . . . . . . . . . . . . . 28		4.4.7. "warnings" JSON Array . . . . . . . . . . . . . . . . 22
	4.9. Delete Authorization . . . . . . . . . . . . . . . . . . 29		4.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 23
	4.10. GS Options . . . . . . . . . . . . . . . . . . . . . . . 29		4.6. Response Verification . . . . . . . . . . . . . . . . . . 24
	4.11. Grant Options . . . . . . . . . . . . . . . . . . . . . . 30		5. Interaction Modes . . . . . . . . . . . . . . . . . . . . . . 24
	4.12. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 30		5.1. "redirect" . . . . . . . . . . . . . . . . . . . . . . . 24
	4.13. Request Verification . . . . . . . . . . . . . . . . . . 30		5.2. "indirect" . . . . . . . . . . . . . . . . . . . . . . . 24
	5. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 31		5.3. "user_code" . . . . . . . . . . . . . . . . . . . . . . . 25
	6. GS Responses . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 31
	6.2. Interaction Response . . . . . . . . . . . . . . . . . . 32
	6.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 33
	6.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 34
	6.4.1. "client" Object . . . . . . . . . . . . . . . . . . . 34
	6.4.2. "interaction" Object . . . . . . . . . . . . . . . . 34
	6.4.3. "user" Object . . . . . . . . . . . . . . . . . . . . 34
	6.4.4. "authorization" Object . . . . . . . . . . . . . . . 34
	6.4.5. "authorizations" Object . . . . . . . . . . . . . . . 34
	6.4.6. "claims" Object . . . . . . . . . . . . . . . . . . . 35
	6.5. Authorization JSON . . . . . . . . . . . . . . . . . . . 35
	6.5.1. Signing and Encryption . . . . . . . . . . . . . . . 36
	6.6. Response Verification . . . . . . . . . . . . . . . . . . 36
	7. interaction mode Objects . . . . . . . . . . . . . . . . . . 36
	7.1. "redirect" mode . . . . . . . . . . . . . . . . . . . . . 37
	7.1.1. request "interaction" object contains: . . . . . . . 37
	7.1.2. response "interaction" object contains: . . . . . . . 37
	7.2. "indirect" mode . . . . . . . . . . . . . . . . . . . . . 37
	7.2.1. request "interaction" object contains: . . . . . . . 37
	7.2.2. response "interaction" object contains: . . . . . . . 37
	7.3. "user_code" mode . . . . . . . . . . . . . . . . . . . . 37
	7.3.1. request "interaction" object contains: . . . . . . . 38
	7.3.2. response "interaction" object contains: . . . . . . . 38
	8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 38
	9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 38
	10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 38
	10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 39
	10.1.1. Authorization Header . . . . . . . . . . . . . . . . 40
	10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 41
	10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 42
	10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 42
	10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 43
	10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 43
	10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 44
	10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 45
	10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 45
	10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 45
	10.5. Response Encryption . . . . . . . . . . . . . . . . . . 46
	11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46
	12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
	16.1. Normative References . . . . . . . . . . . . . . . . . . 51
	16.2. Informative References . . . . . . . . . . . . . . . . . 53
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 54		6. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 54		7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 26
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 54		8. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 55		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 26
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 55		10. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 55		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 55		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 55		13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	A.8. draft-hardt-xauth-protocol-07 . . . . . . . . . . . . . . 56		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 56		14.1. Normative References . . . . . . . . . . . . . . . . . . 29
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57		14.2. Informative References . . . . . . . . . . . . . . . . . 31
			Appendix A. Document History . . . . . . . . . . . . . . . . . . 31
			A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 31
			A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 31
			A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 32
			A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 32
			A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 32
			A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 32
			A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 33
			A.8. draft-hardt-xauth-protocol-07 . . . . . . . . . . . . . . 33
			A.9. draft-hardt-xauth-protocol-08 . . . . . . . . . . . . . . 33
			Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 33
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	This protocol supports the widely deployed use cases supported by		This document describes the core Grant Negotiation and Authorization
	OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an		Protocol (GNAP). The protocol supports the widely deployed use cases
	extension of OAuth 2.0, as well as other extensions, and other use		supported by OAuth 2.0 [RFC6749] & [RFC6750], OpenID Connect [OIDC] -
	cases that are not supported, such as acquiring multiple access		an extension of OAuth 2.0, as well as other extensions. Related
	tokens at the same time, and updating the request during user		documents include: GNAP - Advanced Features [GNAP_Advanced] and JOSE
	interaction. This protocol also addresses many of the security		Authentication [JOSE_Authentication] that describes the JOSE
	issues in OAuth 2.0 by having parameters securely sent directly		mechanisms for client authentication.
	between parties, rather than via a browser redirection.
	The technology landscape has changed since OAuth 2.0 was initially		The technology landscape has changed since OAuth 2.0 was initially
	drafted. More interactions happen on mobile devices than PCs.		drafted. More interactions happen on mobile devices than PCs.
	Modern browsers now directly support asymetric cryptographic		Modern browsers now directly support asymetric cryptographic
	functions. Standards have emerged for signing and encrypting tokens		functions. Standards have emerged for signing and encrypting tokens
	with rich payloads (JOSE) that are widely deployed.		with rich payloads (JOSE) that are widely deployed.
	Additional use cases are now being served with extensions to OAuth		GNAP simplifies the overall architectural model, takes advantage of
	2.0: OpenID Connect added support for authentication and releasing		today's technology landscape, provides support for all the widely
	identity claims; [RFC8252] added support for native apps; [RFC8628]		deployed use cases, offers numerous extension points, and addresses
	added support for smart devices; and support for [browser_based_apps]		many of the security issues in OAuth 2.0 by passing parameters
	is being worked on. There are numerous efforts on adding proof-of-		securely between parties, rather than via a browser redirection. .
	possession to resource access.
	This protocol simplifies the overall architectural model, takes		While GNAP is not backwards compatible with OAuth 2.0, it strives to
	advantage of today's technology landscape, provides support for all		minimize the migration effort.
	the widely deployed use cases, and offers numerous extension points.
	While this protocol is not backwards compatible with OAuth 2.0, it		GNAP centers around a Grant, a representation of the collection of
	strives to minimize the migration effort.		user identity claims and/or resource authorizations the Client is
			requesting, and the resulting identity claims and/or resource
			authorizations granted by the Grant Server (GS).
	This protocol centers around a Grant, a representation of the		User consent is often required at the GS. GNAP enables a Client and
	collection of user identity claims and/or resource authorizations the		GS to negotiate the interaction mode for the GS to obtain consent.
	Client is requesting, and the resulting identity claims and/or
	resource authorizations granted by the Grant Server.
	[Editor: suggestions on how to improve this are welcome!]		The suggested pronunciation of GNAP is the same as the English word
			"nap", a silent "g" as in "gnaw".
	[Editor: suggestions for other names than XAuth are welcome!]		_[Editor: suggestions on how to improve this are welcome!]_
	1.1. Parties		1.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) |
	+--------+ +------------+		+--------+ +------------+
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ / |		| \ / |
	+--------+ +---------------+ +------------+		+--------+ +---------------+ +------------+
	| Client |---->| Grant | _ _ | Resource |		| Client |---->| Grant | | Resource |
	| |<----| Server (GS) | | Server |		| | (1) | Server (GS) | _ _ | Server |
	| | +---------------+ | (RS) |		| |<----| | | (RS) |
	| |-------------------------->| |		| | +---------------+ | |
	| |<--------------------------| |		| |-------------------------->| |
	+--------+ +------------+		| | (2) | |
			| |<--------------------------| |
			+--------+ +------------+
			This document specifies interactions between the Client and GS (1),
			and the Client and RS (2).
	* *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, verify, retrieve, update, and delete a		The Grant may include access tokens that the Client uses to access
	Grant. When a Grant is created, the Client receives from the GS		the RS. There are two types of Clients: Registered Clients and
	the granted access token(s) for the RS(s), and identity claims		Dynamic Clients. All Clients have a private asymetric key to
	about the User. The Client uses an access token to access the RS.		authenticate with the Grant Server.
	There are two types of Clients: Registered Clients and Dynamic
	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 previously
	GS, and each instance will generate it's own key pair so it can		registered with the GS, and each instance will generate it's own
	prove it is the same instance of the Client on subsequent		asymetric key pair so it can prove it is the same instance of the
	requests, and to requests of a Resource Server that require proof-		Client on subsequent requests. The GS MAY return a Dynamic Client
	of-possession access. A single-page application with no active		a Client Handle for the Client to identify itself in subsequent
	server component is an example of a Dynamic Client. A Dynamic		requests. A single-page application with no active server
	Client MUST be interacting with a User.		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. A 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. Some, or all of the resources are owned by the		token from the GS. Some, or all of the resources are owned by the
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 13 ¶
	* *authN* - short for authentication.		* *authN* - short for authentication.
	* *authZ* - short for authorization.		* *authZ* - short for authorization.
	1.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, and is 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. The GS MAY invalidate a Grant at any
			time.
	* *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 and
	Contains an access token.		contains an access token. The GS may invalidate an Authorization
			at any time.
	* *Authorization URI* (AZ URI) - the URI that represents the		* *Authorization URI* (AZ URI) - the URI that represents the
	Authorization the Client was granted by the RO. The AZ URI MUST		Authorization the Client was granted by the RO. The AZ URI MUST
	start with the GS URI. The AZ URI is used to read, update, and		start with the GS URI. The AZ URI is used to refresh an access
	delete an access token.		token.
	* *Interaction* - how the Client directs the User to interact with		* *Interaction* - how the Client directs the User to interact with
	the GS. This document defines the interaction modes redirect,		the GS. This document defines the interaction modes: "redirect",
	indirect, and user_code in Section 7		"indirect", and "user_code" in Section 5
	* *Client Handle* - a GS unique identifier for a Dynamic Client for		* *Client Handle* - a unique identifier at the GS for a Dynamic
	the Dynamic Client to refer to itself in subsequent requests.		Client for the Dynamic Client to refer to itself in subsequent
			requests.
	1.4. Notational Conventions		1.4. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	specification are to be interpreted as described in [RFC2119].		specification are to be interpreted as described in [RFC2119].
	Certain security-related terms are to be understood in the sense		Certain security-related terms are to be understood in the sense
	defined in [RFC4949]. These terms include, but are not limited to,		defined in [RFC4949]. These terms include, but are not limited to,
	"attack", "authentication", "authorization", "certificate",		"attack", "authentication", "authorization", "certificate",
	"confidentiality", "credential", "encryption", "identity", "sign",		"confidentiality", "credential", "encryption", "identity", "sign",
	"signature", "trust", "validate", and "verify".		"signature", "trust", "validate", and "verify".
			_[Editor: review terms]_
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.		are case sensitive.
	Some protocol parameters are parts of a JSON document, and are		Some protocol parameters are parts of a JSON document, and are
	referred to in JavaScript notation. For example, foo.bar refers to		referred to in JavaScript notation. For example, foo.bar refers to
	the "bar" boolean attribute in the "foo" object in the following		the "bar" boolean attribute in the "foo" object in the following
	example JSON document:		example JSON document:
	{		{
	"foo" : {		"foo" : {
	"bar": true		"bar": true
	}		}
	}		}
	2. Sequences		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 4.10		programmatically configured for the GS. See GS Options Section 3.6
	for details on acquiring GS metadata.		for details on programmatically acquiring GS metadata.
	[Editor: a plethora of sequences are included to illustrate all the
	different use cases that are supported. Many sequences are similar,
	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.]
	2.1. Create and Verify Grant		2.1. "redirect" Interaction
	A Dynamic Client wants a Grant from the User using a Redirect		The Client is a web application and wants a Grant from the User:
	Interaction:
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| | +------+		| |<--- Interaction Response ---(2)--| | +------+
	| | | | | User |		| | | | | User |
	| |--(3)--- Interaction Transfer --- | - - - | ------->| |		| |--(3)--- Interaction Transfer --- | - - - | ------->| |
	| | | | | |
	| | | |<--(4)-->| |		| | | |<--(4)-->| |
	| | | | authN | |		| | | | authN | |
			| | | | | |
	| | | |<--(5)-->| |		| | | |<--(5)-->| |
	| | | | authZ | |		| | | | authZ | |
	| |<--- Interaction Transfer ---(6)- | - - - | --------| |		| |<--- Interaction Transfer ---(6)- | - - - | --------| |
	| | | | | |		| | | | | |
	| |--(7)--- Verify Grant ----------->| | +------+		| |--(7)--- Read Grant ------------->| | +------+
	| | | |		| | | |
	| |<--------- Grant Response ---(8)--| |		| |<--------- Grant Response ---(8)--| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Create Grant* The Client creates a Request JSON document		1. *Create Grant* The Client creates a Request JSON document
	Section 4.6 and makes a Create Grant request (Section 4.1) by		Section 3.4 containing an interaction.redirect object and makes a
	sending the JSON with an HTTP POST to the GS URI.		Create Grant request (Section 3.2) by sending the JSON with an
			HTTP POST to the GS URI.
	2. *Interaction Response* The GS determines that interaction with		2. *Interaction Response* The GS determines that interaction with
	the User is required and sends an Interaction Response		the User is required and sends an Interaction Response
	(Section 6.2) containing the Grant URI and an interaction object.		(Section 4.2) containing the Grant URI and an
			interaction.redirect object.
	3. *Interaction Transfer* The Client redirects the User to the		3. *Interaction Transfer* The Client redirects the User to the
	Redirect URI at the GS.		authorization_uri at the GS.
	4. *User Authentication* The GS authenticates the User.		4. *User Authentication* The GS authenticates the User.
	5. *User Authorization* If required, the GS interacts with the User		5. *User Authorization* If required, the GS interacts with the User
	to determine which identity claims and/or authorizations in the		to determine which identity claims and/or authorizations in the
	Grant Request are to be granted.		Grant Request are to be granted.
	6. *Interaction Transfer* The GS redirects the User to the		6. *Interaction Transfer* The GS redirects the User to the
	Completion URI at the Client, passing an Interaction Nonce.		redirect_uri at the Client.
	7. *Read Grant* The Client creates a JSON document containing a		7. *Read Grant* The Client makes an HTTP GET request to the Grant
	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.		URI.
	8. *Grant Response* The GS responds with a Grant Response		8. *Grant Response* The GS responds with a Grant Response
	(Section 6.1).		(Section 4.1).
	2.2. Create and Read Grant - Redirect		2.2. "user_code" Interaction
	A Registered Client wants a Grant from the User using a Redirect		A Client is on a device wants a Grant from the User:
	Interaction:
	+--------+ +-------+		+--------+ +-------+
	| Client | | GS |		| Client | | GS |
	| |--(1)--- Create Grant ----------->| |		| |--(1)--- Create Grant ----------->| |
	| | | |		| | | |
	| |<--- Interaction Response ---(2)--| |		| |<--- Interaction Response ---(2)--| | +------+
	| | | |
	| |--(3)--- Read Grant ------------->| | +------+
	| | | | | User |		| | | | | User |
	| |--(4)--- Interaction Transfer --- | - - - | ------->| |		| |--(3)--- Read Grant ------------->| | | |
	| | | | | |		| | | |<--(4)-->| |
	| | | |<--(5)-->| |
	| | | | authN | |		| | | | authN | |
	| | | |<--(6)-->| |
	| | | | authZ | |
	| |<--------- Grant Response ---(7)--| | | |
	| | | | | |
	| |<--- Interaction Transfer ---(8)- | - - - | --------| |
	| | | | | |		| | | | | |
	+--------+ +-------+ +------+		| | | |<--(5)---| |
			| | | | code | |
	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.
	5. *User Authentication* The GS authenticates the User.
	6. *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.
	7. *Grant Response* The GS responds with a Grant Response
	(Section 6.1).
	8. *Interaction Transfer* The GS redirects the User to the
	Completion URI of the Client. The Client verifies it is the same
	User that it transferred to the GS.
	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)-->| |		| | | |<--(6)-->| |
	| | | | authZ | |		| | | | authZ | |
			| | | | | |
	| |<--------- Grant Response ---(7)--| | | |		| |<--------- Grant Response ---(7)--| | | |
			| | | | | |
	+--------+ | | | |		+--------+ | | | |
	| | | |		| | | |
	+--------+ | | | |		+--------+ | | | |
	| Info |<--- Interaction Transfer ---(8)- | - - - | --------| |		| Client |<----- Completion URI Redirect -- | - - - | --(8)---| |
	| Server | | | | |		| Server | | | | |
	+--------+ +-------+ +------+		+--------+ +-------+ +------+
	The sequence is the same except:		1. *Create Grant* The Client creates a Request JSON document
			Section 3.4 containing an interaction.user_code object and makes
	* In step (4) the User either scans a bar code or uses a separate		a Create Grant request (Section 3.2) by sending the JSON with an
	device to navigate to the Code URI and enters the User Code.		HTTP POST to the GS URI.
	* 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
	like a Grant for the other GS. The sequence starts off the same as
	in Section 2.2, but Party B makes a Create Grant Request before
	sending a Grant Response:
	Party A Party B
	+--------+ +--------+
	| Client | | GS |
	~ ~ ~ ~ ~ ~ Same as steps 1 - 6 of ~ ~ ~ ~ ~ ~
	+------+ | | Create and Read Grant above | |
	| User | | | | |
	| | | GS |<--------- Create Grant ---(1)---| Client |
	| | | | | |
	| | | |<------- Grant Response ---(2)---| |
	| | | | | |
	| |<----- | - - - | -- Interaction Transfer --(3)---| |
	| | | | | |
	| |<-(4)->| | | |
	| | AuthZ | | | |
	+------+ | GS |--(5)--- Grant Response -------->| Client |
	| | | |
	+--------+ +--------+
	1. *Create Grant* Party B creates a Grant Request (Section 4.1) with		2. *Interaction Response* The GS determines that interaction with
	user.reciprocal set to the Party B Grant URI that will be in the		the User is required and sends an Interaction Response
	step (2) Grant Response, and sends it with an HTTP POST to the		(Section 4.2) containing the Grant URI and an
	Party A GS URI. This enables Party A to link the reciprocal		interaction.user_code object.
	Grants.
	2. *Grant Response* Party B responds to Party A's Create Grant		3. *Read Grant* The Client makes an HTTP GET request to the Grant
	Request with a Grant Response that includes the Party B Grant
	URI.		URI.
	3. *Interaction Transfer* Party B redirects the User to the		4. *User Authentication* The User loads display_uri in their
	Completion URI at Party A.		browser, and the GS authenticates the User.
	4. *User Authorization* If required, Party A interacts with the User
	to determine which identity claims and/or authorizations in Party
	B's Create Grant Request are to be granted.
	5. *Grant Response* Party A responds with a Grant Response
	(Section 6.1).
	2.5. GS Initiated Grant
	The User is at the GS, and wants to interact with a Registered
	Client. The GS can redirect the User to the Client:
	+--------+ +-------+ +------+
	| Client | | GS | | User |
	| | | |<--(1)-->| |
	| | | | | |
	| |<----- GS Initiation Redirect --- | - - - | --(2)---| |
	| (3) | | | | |
	| verify |--(4)--- Read Grant ------------->| | +------+
	| | | |
	| |<--------- Grant Response --(5)---| |
	| | | |
	+--------+ +-------+
	1. *User Interaction* The GS interacts with the User to determine
	the Client and what identity claims and authorizations to
	provide. The GS creates a Grant and corresponding Grant URI.
	2. *GS Initiated Redirect* The GS redirects the User to the Client's
	interaction_uri, adding a query parameter with the name "Grant
	URI" and the value being the URL encoded Grant URI.
	3. *Client Verification* The Client verifies the Grant URI is from
	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
	(Section 4.3).
	5. *Grant Response* The GS responds with a Grant Response
	(Section 6.1).
	See Section 5 for more details.
	2.6. Create and Update
	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
	Grant for additional identity claims which the GS prompts the User
	for and returns to the Client. Once those are received, the Client
	updates the Grant with the remaining identity claims required.
	+--------+ +-------+
	| Client | | GS |
	| |--(1)--- Create Grant ----------->| |
	| | interaction.keep:true | |
	| | | |
	| |<--- Interaction Response ---(2)--| |
	| | | |
	| |--(3)--- Read Grant ------------->| | +------+
	| | | | | User |
	| |--(4)--- Interaction Transfer --- | - - - | ------->| |
	| | | | | |
	| | | |<--(5)-->| |
	| | | | authN | |
	| |<--------- Grant Response ---(6)--| | | |
	| (7) | | | | |
	| eval |--(8)--- Update Grant ----------->| | | |
	| | interaction.keep:true | |<--(9)-->| |
	| | | | authZ | |
	| |<--------- Grant Response --(10)--| | | |
	| (11) | | | | |
	| eval |--(12)-- Update Grant ----------->| | | |
	| | interaction.keep:false | |<--(13)->| |
	| | | | authZ | |
	| | | | | |
	| |<--- Interaction Transfer --(14)- | - - - | --------| |
	| | | | | |
	| |<--------- Grant Response --(15)--| | +------+
	| | | |
	+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	including an identity claim and interaction.keep:true, and sends
	it with an HTTP POST to the GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response
	(Section 6.2) containing the Grant URI, an interaction object,
	and interaction.keep:true.
	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.
	5. *User Authentication* The GS authenticates the User.
	6. *Grant Response* The GS responds with a Grant Response
	(Section 6.1) including the identity claim from User
	authentication and interaction.keep:true.
	7. *Grant Evaluation* The Client queries its User database and does
	not find a User record matching the identity claim.
	8. *Update Grant* The Client creates an Update Grant Request
	(Section 4.4) including the initial identity claims required and
	interaction.keep:true, and sends it with an HTTP PUT to the
	Grant URI.
	9. *User AuthN* The GS interacts with the User to determine which
	identity claims in the Update Grant Request are to be granted.
	10. *Grant Response* The GS responds with a Grant Response
	(Section 6.1) including the identity claims released by the User
	and interaction.keep:true.
	11. *Grant Evaluation* The Client evaluates the identity claims in
	the Grant Response and determines the remaining User identity
	claim required.
	12. *Update Grant* The Client creates an Update Grant Request
	(Section 4.4) including the remaining required identity claims
	and interaction.keep:false, and sends it with an HTTP PUT to the
	Grant URI.
	13. *User AuthZ* The GS interacts with the User to determine which
	identity claims in the Update Grant Request are to be granted.
	14. *Interaction Transfer* The GS transfers User interaction to the
	Client.
	15. *Grant Response* The GS responds with a Grant Response
	(Section 6.1) including the identity claims released by the
	User.
	2.7. Create and Delete
	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
	already has all the identity claims and authorizations needed for the
	User, the Client deletes the Grant which prompts the GS to transfer
	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 |
	| |--(1)--- Create Grant ----------->| |
	| | interaction.keep:true | |
	| | | |
	| |<--- Interaction Response ---(2)--| |
	| | | |
	| |--(3)--- Read Grant ------------->| | +------+
	| | | | | User |
	| |--(4)--- Interaction Transfer --- | - - - | ------->| |
	| | | | | |
	| | | |<--(5)-->| |
	| | | | authN | |
	| |<--------- Grant Response ---(6)--| | | |
	| (7) | | | | |
	| eval |--(8)--- Delete Grant ----------->| | | |
	| |<------- Delete Response ---------| | | |
	| | | | | |
	| |<--- Interaction Transfer ---(9)- | - - - | --------| |
	| | | | | |
	+--------+ +-------+ +------+
	1. *Create Grant* The Client creates a Grant Request (Section 4.1)
	including an identity claim and interaction.keep:true, and sends
	it with an HTTP POST to the GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response
	(Section 6.2) containing the Grant URI, an interaction object,
	and interaction.keep:true.
	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.
	5. *User Authentication* The GS authenticates the User.
	6. *Grant Response* The GS responds with a Grant Response
	(Section 6.1) including the identity claim from User
	authentication and interaction.keep:true.
	7. *Grant Evaluation* The Client queries its User database and finds
	the User record matching the identity claim, and that no
	additional claims or authorizations are required.
	8. *Delete Grant* The Client no longer needs the Grant and decides
	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
	exists.
	2.8. Create, Discover, and Delete
	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
	interaction to the GS.
	+--------+ +-------+		5. *User Code* The User enters the code at the GS.
	| Client | | GS |
	| |--(1)--- Create Grant ----------->| |
	| | user.exists:true | |
	| | | |
	| |<--- Interaction Response ---(2)--| |
	| | user.exists:false | |
	| | | |
	| |--(3)--- Delete Grant ----------->| |
	| |<------- Delete Response ---------| |
	| | | |
	+--------+ +-------+
	1. *Create Grant* The Client creates a Grant Request (Section 4.1)		6. *User Authorization* If required, the GS interacts with the User
	including an identity claim request, a User identifier, and		to determine which identity claims and/or authorizations in the
	user.exists:true. The Client sends it with an HTTP POST to the		Grant Request are to be granted.
	GS GS URI.
	2. *Interaction Response* The GS sends an Interaction Response		7. *Grant Response* The GS responds with a Grant Response
	(Section 6.2) containing the Grant URI, an interaction object,		(Section 4.1).
	and user.exists:false.
	3. *Delete Grant* The Client determines the GS cannot fulfil its		8. *Completion URI Redirect* The GS redirects the User to the
	Grant Request, and decides to Delete Grant (Section 4.5) by		completion_uri provided by the Client.
	sending an HTTP DELETE to the Grant URI. If the GS responds with
	success the Grant no longer exists.
	2.9. Create and Wait		2.3. Independent RO Authorization
	The Client wants access to resources that require the GS to interact		The Client wants access to resources that require the GS to interact
	with the RO, which may not happen immediately, so the GS instructs		with the RO, who is not interacting with the Client. The
	the Client to wait and check back later.		authorization from the RO may take some time, so the GS instructs 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 4.1)		1. *Create Grant* The Client creates a Grant Request (Section 3.2)
	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 Wait Response (Section 4.3)
	(Section 6.3) containing the Grant URI and wait time.		containing the Grant URI and the "wait" attribute.
	3. *Client Waits* The Client waits the wait time.		3. *Client Waits* The Client waits for the time specified in the
			"wait" attribute.
	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 and/or resource authorizations 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 4.3).		(Section 3.3).
	6. *Grant Response* The GS responds with a Grant Response		6. *Grant Response* The GS responds with a Grant Response
	(Section 6.1).		(Section 4.1).
	2.10. Read Grant
	The Client wants to re-acquire the identity claims and authorizations
	in the Grant. No User or RO interaction is required as no new
	consent or authorization is required.
	+--------+ +-------+
	| Client | | GS |
	| |--(1)--- Read Grant ------------->| |
	| | | |
	| |<--------- Grant Response --(2)---| |
	| | | |
	+--------+ +-------+
	1. *Read Grant* The Client does an HTTP GET of the Grant URI
	(Section 4.3).
	2. *Grant Response* The GS responds with a Grant Response
	(Section 6.1) containing updated identity claims and
	authorizations.
	2.11. Resource Server Access		2.4. Resource Server Access
	The Client received an AZ URI from the GS. The Client acquires an		The Client received an AZ URI from the GS. The Client acquires an
	access token, calls the RS, and later the access token expires. The		access token, calls the RS, and later the access token expires. The
	Client then gets a fresh access token.		Client then gets a fresh access token.
	+--------+ +-------+		+--------+ +----------+ +-------+
	| Client | | GS |		| Client | | Resource | | GS |
	| |--(1)--- Read AuthZ ---------------------->| |		| |--(1)--- Access Resource --->| Server | | |
	| |<------- AuthZ Response -------------------| |
	| | | |
	| | +----------+ | |
	| | | Resource | | |
	| |--(2)--- Access Resource --->| Server | | |
	| |<------- Resource Response --| (RS) | | |		| |<------- Resource Response --| (RS) | | |
	| | | | | |		| | | | | |
	| |--(3)--- Access Resource --->| | | |		| |--(2)--- Access Resource --->| | | |
	| |<------- Error Response -----| | | |		| |<------- Error Response -----| | | |
	| | | | | |		| | | | | |
	| | +----------+ | |		| | +----------+ | |
	| | | |		| | | |
	| |--(4)--- Read AuthZ ---------------------->| |		| |--(3)--- Read AuthZ ---------------------->| |
	| |<------- AuthZ Response -------------------| |		| |<------- AuthZ Response -------------------| |
	| | | |		| | | |
	+--------+ +-------+		+--------+ +-------+
	1. *Read AuthZ* The Client makes a Read AuthZ (Section 4.7) with an		1. *Resource Request* The Client accesses the RS with the access
			token per Section 6 and receives a response from the RS.
			2. *Resource Request* The Client attempts to access the RS, but
			receives an error indicating the access token needs to be
			refreshed.
			3. *Read AuthZ* The Client makes a Read AuthZ (Section 3.5) with an
	HTTP GET to the AZ URI and receives an Response JSON		HTTP GET to the AZ URI and receives an Response JSON
	"authorization" object (Section 6.4.4) with a fresh access token.		"authorization" object (Section 4.4.4) with a fresh access token.
	2. *Resource Request* The Client accesses the RS with the access		3. GS APIs
	token per Section 8 and receives a response from the RS.
	3. *Resource Request* The Client attempts to access the RS, but		*Client Authentication*
	receives an error indicating the access token has expired.
	4. *Read AuthZ* The Client makes another Read AuthZ (Section 4.7)		All GS APIs except for GS Options require the Client to authenticate.
	with an HTTP GET to the AZ URI and receives an Response JSON		Authentication mechanisms include:
	"authorization" object (Section 6.4.4) with a fresh access token.
	2.12. GS API Table		* JOSE Authentication [JOSE_Authentication]
			* [Others TBD]*
			3.1. GS API Table
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| request | http verb | uri | response |		| request | http verb | uri | response |
	+==============+===========+========+=============================+		+==============+===========+========+=============================+
	| Create Grant | POST | GS URI | interaction, wait, or grant |		| GS Options | OPTIONS | GS URI | metadata |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Verify Grant | PATCH | Grant | grant |		| Create Grant | POST | GS URI | interaction, wait, or 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 |
	| | | URI | |
	+--------------+-----------+--------+-----------------------------+
	| Delete Grant | DELETE | Grant | success |
	| | | URI | |
	+--------------+-----------+--------+-----------------------------+
	| Read AuthZ | GET | AZ URI | authorization |		| Read AuthZ | GET | AZ URI | authorization |
	+--------------+-----------+--------+-----------------------------+		+--------------+-----------+--------+-----------------------------+
	| Update AuthZ | PUT | AZ URI | authorization |
	+--------------+-----------+--------+-----------------------------+
	| Delete AuthZ | DELETE | AZ URI | success |
	+--------------+-----------+--------+-----------------------------+
	| GS Options | OPTIONS | GS URI | metadata |
	+--------------+-----------+--------+-----------------------------+
	| Grant | OPTIONS | Grant | metadata |
	| Options | | URI | |
	+--------------+-----------+--------+-----------------------------+
	| AuthZ | OPTIONS | AZ URI | metadata |
	| Options | | | |
	+--------------+-----------+--------+-----------------------------+
	Table 1		Table 1
	[ Editor: is there value in an API for listing a Client's Grants?		3.2. Create Grant
	eg:]
	List Grants GET GS URI JSON array of Grant URIs
	3. Grant and AuthZ Life Cycle
	[Editor: straw man for life cycles.]
	*Grant life Cycle*
	The Client MAY create, read, update, and delete Grants. A Grant
	persists until it has expired, is deleted, or another Grant is
	created for the same GS, Client, and User tuple.
	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
	same User, the GS MUST invalidate a previous Grant for the Client at
	that GS for that User.
	*Authorization Life Cycle*
	An Authorization are represented by an AZ URI and are MAY be included
	in a Grant Response "authorization" Object (Section 6.4.4) or as a
	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
	until invalidated by the GS per GS policy, or deleted by the Client.
	4. GS APIs
	*Client Authentication*
	All APIs except for GS Options require the Client to authenticate.
	This document defines the JOSE Authentication mechanism in
	Section 10. Other mechanisms include [TBD].
	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. This is a Greant Request.
	The JSON document MUST include the following from the Request JSON		The JSON document MUST include the following from the Request JSON
	Section 4.6:		Section 3.4:
	* 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 4.6		and MAY include the following from Request JSON Section 3.4
	* user		* user
	* interaction		* interaction
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	The GS MUST respond with one of Grant Response Section 6.1,		The GS MUST respond with one of Grant Response Section 4.1,
	Interaction Response Section 6.2, Wait Response Section 6.3, or one		Interaction Response Section 4.2, Wait Response Section 4.3, or one
	of the following errors:		of the following errors:
	* TBD		* TBD
			from Error Responses Section 7.
	from Error Responses Section 9.		Following is a non-normative example of a web application Client
			requesting identity claims about the User and read access to the
	Following is a non-normative example where the Client is requesting		User's contacts:
	identity claims about the User and read access to the User's
	contacts:
	Example 1		Example 1
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"client": {		"client": {
	"display": {		"display": {
	"name" : "SPA Display Name",		"name" : "SPA Display Name",
	skipping to change at page 22, line 43 ¶		skipping to change at page 13, line 48 ¶
	"email_verified" : { "essential" : true }		"email_verified" : { "essential" : true }
	},		},
	"userinfo" : {		"userinfo" : {
	"name" : { "essential" : true },		"name" : { "essential" : true },
	"picture" : null		"picture" : null
	}		}
	}		}
	}		}
	}		}
	Following is a non-normative example where the Client is requesting		Following is a non-normative example of a device Client requesting
	the GS to keep the interaction with the User after returning the ID		access to play music:
	Token so the Client can update the Grant, and is also asking if the
	user exists:
	Example 2		Example 2
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"client": {		"client": {
	"id" : "di3872h34dkJW"		"id" : "di3872h34dkJW"
	},		},
	"interaction": {		"interaction": {
	"indirect": {		"indirect": {
	"completion_uri": "https://device.example/completion"		"completion_uri": "https://device.example/c/indirect"
	},		},
	"user_code": {		"user_code": {
	"completion_uri": "https://device.example/completion"		"completion_uri": "https://device.example/c/user_code"
	}		}
	},		},
	"user": {		"authorization": {
	"identifiers": {		"type" : "oauth_scope",
	"email" : "jane.doe@example.com"		"scope" : "play_music"
	},
	"exists" : true
	},
	"claims" : { "oidc": { "id_token" : {} } }
	}
	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
	Grant URI.
	The GS MUST respond with one of Grant Response Section 6.1, Wait
	Response Section 6.3, or one of the following errors:
	* TBD
	from Error Responses Section 9.
	4.4. Update Grant
	The Client updates a Grant by doing an HTTP PUT of a JSON document to
	the corresponding Grant URI.
	The JSON document MUST include the following from the Request JSON
	Section 4.6
	* iat
	* uri set to the Grant URI
	and MAY include the following from Request JSON Section 4.6
	* user
	* interaction
	* authorization or authorizations
	* claims
	The GS MUST respond with one of Grant Response Section 6.1,
	Interaction Response Section 6.2, Wait Response Section 6.3, or one
	of the following errors:
	* TBD
	from Error Responses Section 9.
	Following is a non-normative example where the Client made an
	interaction.keep:true request, and now wants to update the request
	with additional claims:
	Example 3
	{
	"iat" : 15790460234,
	"uri" : "https://as.example/endpoint/grant/example3",
	"claims": {
	"oidc": {
	"userinfo" : {
	"email" : { "essential" : true },
	"name" : { "essential" : true },
	"picture" : null
	}
	}
	}		}
	}		}
	4.5. Delete Grant		3.3. Read Grant
	The Client deletes a Grant by doing an HTTP DELETE of the		The Client reads a Grant by doing an HTTP GET of the corresponding
	corresponding Grant URI.		Grant URI. The Client MAY read a Grant until it expires or has been
			invalidated.
	The GS MUST respond with OK 200, or one of the following errors:		The GS MUST respond with one of Grant Response Section 4.1, Wait
			Response Section 4.3, or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		3.4. Request JSON
	4.6. Request JSON
	[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 4.1, or the Grant		* *uri* - the GS URI
	URI if in an Update Grant Section 4.4.
	4.6.1. "client" Object		3.4.1. "client" Object
	The client object MUST contain one of: the "id" attribute for a		The client object MUST only one of the following:
	Registered Client, the "handle" attribute for a Dynamic Client, or
	the "display" object for Dynamic Clients.
	* *id* - the Client ID the GS has for a Registered Client.		* *id* - the Client ID the GS has for a Registered Client.
	* *handle* = the Client Handle the GS previously provided a Dynamic		* *handle* - the Client Handle the GS previously provided a Dynamic
	Client		Client
	* *display* - the display object contains the following attributes:		* *display* - the display object contains the following attributes:
	- *name* - a string that represents the Dynamic Client		- *name* - a string that represents the Dynamic Client
	- *uri* - a URI representing the Dynamic Client		- *uri* - a URI representing the Dynamic Client
	The name and uri will be displayed by the GS when prompting for		The GS will show the the User the display.name and display.uri values
	authorization.		when prompting for authorization.
	[Editor: a max length for the name and URI so a GS can reserve		_[Editor: a max length for the name and URI so a GS can reserve
	appropriate space?]		appropriate space?]_
	4.6.2. "interaction" Object		3.4.2. "interaction" Object
	The interaction object contains one or more interaction mode objects		The interaction object contains one or more interaction mode objects
	per Section 7 representing the interactions the Client is willing to		per Section 5 representing the interactions the Client is willing to
	provide the User. In addition to the interaction mode objects, the		provide the User. In addition to the interaction mode objects, the
	interaction object may contain the "global" object;		interaction object may contain the "global" object;
	* *global* - and optional object containing parameters that are		* *global* - an optional object containing parameters that are
	applicable for all types of interactions. Only one attribute is		applicable for all interaction modes. Only one attribute is
	defined in this document:		defined in this document:
	- *ui_locales* - End-User's preferred languages and scripts for		- *ui_locales* - End-User's preferred languages and scripts for
	the user interface, represented as a space-separated list of		the user interface, represented as a space-separated list of
	[RFC5646] language tag values, ordered by preference. This		[RFC5646] language tag values, ordered by preference. This
	attribute is OPTIONAL.		attribute is OPTIONAL.
	[Editor: why is this not a JSON array? Why space-separated?]		_[Editor: ui_locales is taken from OIDC. Why space-separated and not
			a JSON array?]_
	4.6.3. "user" Object
	* *exists* - if present, MUST contain the JSON true value.		3.4.3. "user" Object
	Indicates the Client requests the GS to return a user.exists value
	in an Interaction Response Section 6.2. This attribute is
	OPTIONAL, and MAY be ignored by the GS.
	* *identifiers* - REQUIRED if the exists attribute is present. The		* *identifiers* - The identifiers MAY be used by the GS to improve
	values MAY be used by the GS to improve the User experience.		the User experience. This object contains one or more of the
	Contains one or more of the following identifiers for the User:		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* - is an object containing both the "iss" and "sub"		- *oidc* - is an object containing both the "iss" and "sub"
	attributes from an OpenID Connect ID Token [OIDC] Section 2.		attributes from an OpenID Connect ID Token [OIDC] Section 2.
	* *claims* - an optional object containing one or more assertions		* *claims* - an optional object containing one or more assertions
	the Client has about the User.		the Client has about the User.
	- *oidc_id_token* - an OpenID Connect ID Token per [OIDC]		- *oidc_id_token* - an OpenID Connect ID Token per [OIDC]
	Section 2.		Section 2.
	* *reciprocal* - indicates this Grant Request or Update is the		3.4.4. "authorization" Object
	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]_
	4.6.5. "authorizations" Object		3.4.5. "authorizations" Object
	One or more key / value pairs, where each unique key is created by		One or more key / value pairs, where each unique key is created by
	the client, and the value is an authorization object.		the client, and the value is an authorization object per
			Section 3.4.4.
	4.6.6. "claims" Object		3.4.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
	containing no additional Claims.		containing no additional Claims.
	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 can be
	be requested.]		requested.]_[W3C_VC]
	4.6.7. "verification" Object
	The verification Object is used with the Verify Grant Section 4.2.
	* *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
	Response signed and/or encrypted?]
	4.7. Read Authorization
	The Client acquires an Authorization by doing an HTTP GET to the
	corresponding AZ URI.
	The GS MUST respond with a Authorization JSON document Section 6.5,
	or one of the following errors:
	* TBD
	from Error Responses Section 9.
	4.8. Update Authorization
	The Client updates an Authorization by doing an HTTP PUT to the
	corresponding AZ URI of the following JSON. All of the following
	MUST be included.
	* *iat* - the time of the response as a NumericDate.
	* *uri* - the AZ URI.		3.5. Read Authorization
	* *authorization* - the new authorization requested per the Request		The Client acquires and refreshes an Authorization by doing an HTTP
	JSON "authorization" object Section 4.6.4.		GET to the corresponding AZ URI.
	The GS MUST respond with a Authorization JSON document Section 6.5,		The GS MUST respond with a Authorization JSON document Section 4.5,
	or one of the following errors:		or one of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 7.
	4.9. Delete Authorization
	The Client deletes an Authorization by doing an HTTP DELETE to the
	corresponding AZ URI.
	The GS MUST respond with OK 200, or one of the following errors:
	* TBD
	from Error Responses Section 9.
	4.10. GS Options		3.6. 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]
	* *uri* - the GS URI.		* *uri* - the GS URI.
	* *client_authentication* - an array of the Client Authentication		* *client_authentication* - a JSON array of the Client
	mechanisms supported by the GS		Authentication mechanisms supported by the GS
	* *interactions* - an array of the interaction modes supported by		* *interactions* - a JSON array of the interaction modes supported
	the GS.		by the GS.
	* *authorization* - an object containing the authorizations the		* *authorization* - an object containing the authorizations the
	Client may request from the GS, if any.		Client may request from the GS, if any.
	- Details TBD		- Details TBD
	* *claims* - an object containing the identity claims the Client may		* *claims* - an object containing the identity claims the Client may
	request from the GS, if any, and what public keys the claims will		request from the GS, if any, and what public keys the claims will
	be signed with.		be signed with.
	- Details TBD		- Details TBD
	* *algorithms* - a list of the cryptographic algorithms supported by		* *algorithms* - a JSON array of the cryptographic algorithms
	the GS.		supported by the GS. [details TBD]*
	* *features* - an object containing feature support		* *features* - an object containing feature support
	- *user_exists* - boolean indicating if user.exists is supported.
	- *authorizations* - boolean indicating if a request for more		- *authorizations* - boolean indicating if a request for more
	than one authorization in a request is supported.		than one authorization in a request is supported.
	[Editor: keys used by Client to encrypt requests, or verify signed
	responses?]
	[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 7.
	4.11. Grant Options
	The Client can get the metadata for the Grant by doing an HTTP
	OPTIONS of the corresponding Grant URI.
	The GS MUST respond with the the following JSON document:
	* *verbs* - an array of the HTTP verbs supported at the GS URI.
	or one of the following errors:
	* TBD
	from Error Responses Section 9.
	4.12. AuthZ Options
	The Client can get the metadata for the AuthZ by doing an HTTP
	OPTIONS of the corresponding AZ URI.
	The GS MUST respond with the the following JSON document:
	* *verbs* - an array of the HTTP verbs supported at the GS URI.
	or one of the following errors:
	* TBD
	from Error Responses Section 9.
	4.13. Request Verification
	On receipt of a request, the GS MUST verify the following:
	* TBD
	5. GS Initiated Grant
	[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
	redirected back to the AS to initiate a flow.
	Here is a proposal to support GS initiated: authentication; just-in-
	time (JIT) provisioning; and authorization]
	*initiation_uri* A URI at the Client that contains no query or
	fragment. How the GS learns the Client initiation_uri is out of
	scope.
	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
	Grant URI.
	See Section 2.5 for the sequence diagram.
	6. GS Responses		4. GS Responses
	There are three successful responses to a grant request: Grant		There are three successful responses to a Grant Request: Grant
	Response, Interaction Response, or Wait Response.		Response, Interaction Response, or Wait Response.
	6.1. Grant Response		4.1. Grant Response
	The Grant Response MUST include the following from the Response JSON		The Grant Response MUST include the following from the Response JSON
	Section 6.4		Section 4.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	and MAY include the following from the Response JSON Section 6.4		and MAY include the following from the Response JSON Section 4.4
	* client.handle		* client.handle
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
	* expires_in		* expires_in
			* warnings
	Example non-normative Grant Response JSON document for Example 1 in		Example non-normative Grant Response JSON document for Example 1 in
	Section 4.1:		Section 3.2:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"uri" : "https://as.example/endpoint/grant/example1",		"uri" : "https://as.example/endpoint/grant/example1",
	"expires_in" : 300		"expires_in" : 300
	"authorization": {		"authorization": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_contacts",		"scope" : "read_contacts",
	"expires_in" : 3600,		"expires_in" : 3600,
	skipping to change at page 32, line 30 ¶		skipping to change at page 19, line 28 ¶
	"oidc": {		"oidc": {
	"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"
	}		}
	}		}
	}		}
	}		}
			Note in this example the access token can not be refreshed, and
			expires in an hour.
	Example non-normative Grant Response JSON document for Example 2 in		Example non-normative Grant Response JSON document for Example 2 in
	Section 4.1:		Section 3.2:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"uri" : "https://as.example/endpoint/grant/example2",		"uri" : "https://as.example/endpoint/grant/example2",
	"authorization": {		"authorization": {
	"uri" : "https://as.example/endpoint/authz/example2"		"uri" : "https://as.example/endpoint/authz/example2"
	}		}
	}		}
	6.2. Interaction Response		Note in this example the GS only provided the AZ URI, and Client must
			acquire the Authorization per Section 3.5
			4.2. Interaction Response
	The Interaction Response MUST include the following from the Response		The Interaction Response MUST include the following from the Response
	JSON Section 6.4		JSON Section 4.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* interaction		* interaction
	and MAY include the following from the Response JSON Section 6.4		and MAY include the following from the Response JSON Section 4.4
	* user		* user
	* wait		* wait
			* warnings
	A non-normative example of an Interaction Response follows:		A non-normative example of an Interaction Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example4",		"uri" : "https://as.example/endpoint/grant/example4",
	"interaction" : {		"interaction" : {
	""redirect" : {		""redirect" : {
	"authorization_uri" : "https://as.example/i/example4"		"authorization_uri" : "https://as.example/i/example4"
	}		}
	},		},
	"user": {		"user": {
	"exists" : true		"exists" : true
	}		}
	}		}
	6.3. Wait Response		4.3. Wait Response
	The Wait Response MUST include the following from the Response JSON		The Wait Response MUST include the following from the Response JSON
	Section 6.4		Section 4.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* wait		* wait
			and MAY include the following from the Response JSON Section 4.4
			* warnings
	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
	}		}
	6.4. Response JSON		4.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 4.6.		Section 3.4.
	* *uri* - the Grant URI.		* *uri* - the Grant URI.
	* *wait* - a numeric value representing the number of seconds the		* *wait* - a numeric value representing the number of seconds the
	Client should want before making a Read Grant request to the Grant		Client should want before making a Read Grant request to the Grant
	URI.		URI.
	* *expires_in* - a numeric value specifying how many seconds until		* *expires_in* - a numeric value specifying how many seconds until
	the Grant expires. This attribute is OPTIONAL.		the Grant expires. This attribute is OPTIONAL.
	6.4.1. "client" Object		4.4.1. "client" Object
	The GS may		The GS may
	6.4.2. "interaction" Object		4.4.2. "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 an interaction object containing one or more interaction mode		return an interaction object containing one or more interaction mode
	responses per Section 7 to one or more of the interaction mode		responses per Section 5 to one or more of the interaction mode
	requests provided by the Client.		requests provided by the Client.
	6.4.3. "user" Object		4.4.3. "user" Object
	* *exists* - a boolean value indicating if the GS has a user with		* *exists* - a boolean value indicating if the GS has a user with
	one or more of the provided identifiers in the Request		one or more of the provided identifiers in the Request
	user.identifiers object Section 4.6.3		user.identifiers object Section 3.4.3
	6.4.4. "authorization" Object		4.4.4. "authorization" Object
	The authorization object contains Authorization JSON Section 6.5.		The authorization object MUST contain only a "uri" attribute or the
	See Grant Response Section 6.1 for non-normative examples.		following from Authorization JSON Section 4.5:
	6.4.5. "authorizations" Object		* mechanism
			* token
	A key / value pair for each key in the client's request		The authorization object MAY contain any of the following from
	authorizations object, and the value is Authorization JSON		Authorization JSON Section 4.5:
	Section 6.5.
	6.4.6. "claims" Object		* access
	The claims object is a response to the Request "claims" object		* expires_in
	Section 4.6.4.
			* uri
			If there is no "uri" attribute, the access token can not be
			refreshed. If only the "uri" attribute is present, the Client MUST
			acquire the Authorization per Section 3.5
			4.4.5. "authorizations" Object
			A key / value pair for each key in the Grant Request "authorizations"
			object, and the value is per Section 4.4.4.
			4.4.6. "claims" Object
			The claims object is a response to the Grant Request "claims" object
			Section 3.4.4.
	* *oidc*		* *oidc*
	- *id_token* - an OpenID Connect ID Token containing the Claims		- *id_token* - an OpenID Connect ID Token containing the Claims
	the User consented to be released.		the User consented to be released.
	- *userinfo* - the Claims the User consented to be released.		- *userinfo* - the Claims the User consented to be released.
	Claims are defined in [OIDC] Section 5.		Claims are defined in [OIDC] Section 5.
	* *oidc4ia* - OpenID Connect for Identity Assurance claims response		* *oidc4ia* - OpenID Connect for Identity Assurance claims response
	per [OIDC4IA].		per [OIDC4IA].
	* *vc*		* *vc*
	The verified claims the user consented to be released. [Editor:		The verified claims the user consented to be released. _[Editor:
	details TBD]		details TBD]_
	6.5. Authorization JSON		4.4.7. "warnings" JSON Array
	The Authorization JSON is a response to a Read AuthZ request by the		Includes zero or more warnings from Section 8,
	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.5.
	* *type* - the type of claim request: "oauth_scope" or "oauth_rich".		4.5. Authorization JSON
	See the "type" object in Section 4.6.4 for details. This
	attribute is REQUIRED.
	* *scope* - the scopes the Client was granted authorization for.		The Authorization JSON is the contents of a Grant Response
	This will be all, or a subset, of what was requested. This		"authorization" object Section 4.4.5 or the response to a Read AuthZ
	attribute is OPTIONAL.		request by the Client Section 3.5.
	* *authorization_details* - the authorization details granted per		* *type* - the type of claim request: "oauth_scope" or "oauth_rich".
	[RAR]. Included if type is "oauth_rich".		See the "type" object in Section 3.4.4 for details
	* *mechanism* - one of the access mechanisms: "bearer", "jose", or		* *mechanism* - the RS access mechanism. This document defines the
	"jose+body". See Section 8 for details. This attribute is		"bearer" mechanism as defined in Section 6
	REQUIRED.
	* *token* - the access token for accessing an RS. This attribute is		* *token* - the access token for accessing an RS.
	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.
	* *certificate* - MUST be included if the mechanism is "jose" or		* *uri* - the AZ URI. Used to acquire or refresh an authorization.
	"jose+body". Contains the jwk header values for the Client to
	include in the JWS header when calling the RS using the "jose" or
	"jose+body" mechanisms. See Section 10.2.1.
	* *uri* - the AZ URI. Used to refresh an authorization. This		* *access* - an object containing the access granted:
	attribute is OPTIONAL.
	[Editor: would an optional expiry for the Authorization be useful?]		- *type* - the type of claim request: "oauth_scope" or
			"oauth_rich". See the "type" object in Section 3.4.4 for
			details. This attribute is REQUIRED.
	The following is a non-normative example of an Authorization JSON		- *scope* - the scopes the Client was granted authorization for.
	document:		This will be all, or a subset, of what was requested. This
			attribute is OPTIONAL.
			- *authorization_details* - the authorization details granted per
			[RAR]. This attribute is OPTIONAL if "type" is "oauth_rich".
			_[Editor: would an optional expiry for the Authorization be useful?]_
			The following is a non-normative example of Authorization JSON:
	{		{
	"type" : "oauth_scope",		"mechanism" : "bearer",
	"scope" : "read_calendar write_calendar",
	"mechanism" : "jose",
	"token" : "eyJJ2D6.example.access.token.mZf9p"		"token" : "eyJJ2D6.example.access.token.mZf9p"
	"expires_in" : 3600,		"expires_in" : 3600,
	"certificate": {		"uri" : "https://as.example/endpoint/authz/example2",
	"x5u" : "https://as.example/cert/example2"		"access": {
	},		"type" : "oauth_scope",
	"uri" : "https://as.example/endpoint/authz/example2"		"scope" : "read_calendar write_calendar"
			}
	}		}
	6.5.1. Signing and Encryption		4.6. Response Verification
	[Editor: TBD - how response is signed and/or encrypted by the GS. Is
	there a generalized description, or is it mechanism specific?]
	6.6. Response Verification
	On receipt of a response, the Client MUST verify the following:		On receipt of a response, the Client MUST verify the following:
	* TBD		* TBD
	7. interaction mode Objects		5. Interaction Modes
	This document defines three interaction modes: "redirect",		This document defines three interaction modes: "redirect",
	"indirect", and "user_code". Extensions may define additional		"indirect", and "user_code". Extensions may define additional
	interaction modes.		interaction modes.
	The "global" attribute is reserved in the interaction object for		The "global" attribute is reserved in the interaction object for
	attributes that apply to all interaction modes.		attributes that apply to all interaction modes.
	7.1. "redirect" mode		5.1. "redirect"
	A Redirect Interaction is characterized by the Client redirecting the		A Redirect Interaction is characterized by the Client redirecting the
	User's browser to the GS, the GS interacting with the User, and then		User's browser to the GS, the GS interacting with the User, and then
	GS redirecting the User's browser back to the Client. The GS		GS redirecting the User's browser back to the Client. The GS
	correlates the Grant Request with the unique authorization_uri, and		correlates the Grant Request with the unique authorization_uri, and
	the Client correlates the Grant Request with the unique redirect_uri.		the Client correlates the Grant Request with the unique redirect_uri.
	7.1.1. request "interaction" object contains:		*The request "interaction" object contains:*
	*redirect_uri* a grant request request unique URI at the Client that		* *redirect_uri* a unique URI at the Client that the GS will return
	the GS will return the User to. This attribute is REQUIRED.		the User to. The URI MUST not contain the "nonce" from the Grant
			Request, and MUST not be guessable. This attribute is REQUIRED.
	7.1.2. response "interaction" object contains:		*The response "interaction" object contains:*
	*authorization_uri* a grant request request unique URI at the GS that		* *authorization_uri* a unique URI at the GS that the Client will
	the Client will redirect the User to. This attribute is REQUIRED.		redirect the User to. The URI MUST not contain the "nonce" from
			the Grant Request, and MUST not be guessable. This attribute is
			REQUIRED.
	7.2. "indirect" mode		5.2. "indirect"
	An Indirect Interaction is characterized by the Client causing the		An Indirect Interaction is characterized by the Client causing the
	User's browser to load the short_uri at GS, the GS interacting with		User's browser to load the short_uri at GS, the GS interacting with
	the User, and then the GS MAY optionally redirecting the User's		the User, and then the GS MAY optionally redirect the User's Browser
	Browser to a completion_uri. There is no mechanism for the GS to		to a completion_uri. There is no mechanism for the GS to redirect
	redirect the User's browser back to the Client. Examples of how the		the User's browser back to the Client.
	Client may initiate the interaction are encoding the short_uri as a
	code scannable by the User's mobile device, or launching a system		Examples of how the Client may initiate the interaction are encoding
	browser from a command line interface (CLI) application.		the short_uri as a code scannable by the User's mobile device, or
			launching a system browser from a command line interface (CLI)
			application.
	The "indirect" mode is susceptible to session fixation attacks. See		The "indirect" mode is susceptible to session fixation attacks. See
	TBD in the Security Considerations for details.		TBD in the Security Considerations for details.
	7.2.1. request "interaction" object contains:		*The request "interaction" object contains:*
	*completion_uri* an OPTIONAL URI that the GS will redirect the User's		* *completion_uri* an OPTIONAL URI that the GS will redirect the
	browser to after GS interaction.		User's browser to after GS interaction.
	7.2.2. response "interaction" object contains:		*The response "interaction" object contains:*
	*short_uri* the URI the Client will cause to load in the User's		* *short_uri* the URI the Client will cause to load in the User's
	browser. The URI SHOULD be short enough to be easily encoded in a		browser. The URI SHOULD be short enough to be easily encoded in a
	scannable code. [Editor: recommend a length?]		scannable code. The URI MUST not contain the "nonce" from the
			Grant Request, and MUST not be guessable. _[Editor: recommend a
			maximum length?]_
	7.3. "user_code" mode		5.3. "user_code"
	An Indirect Interaction is characterized by the Client displaying a		An Indirect Interaction is characterized by the Client displaying a
	code and a URI for the User to load in a browser and then enter the		code and a URI for the User to load in a browser and then enter the
	code.		code. _[Editor: recommend a minimum entropy?]_
	7.3.1. request "interaction" object contains:		*The request "interaction" object contains:*
	*completion_uri* an OPTIONAL URI that the GS will redirect the User's		* *completion_uri* an OPTIONAL URI that the GS will redirect the
	browser to after GS interaction.		User's browser to after GS interaction.
	7.3.2. response "interaction" object contains:		*The response "interaction" object contains:*
	*code* the code the Client displays to the User to enter at the		* *code* the code the Client displays to the User to enter at the
	display_uri. This attribute is REQUIRED.		display_uri. This attribute is REQUIRED.
	*display_uri* the URI the Client displays to the User to load in a		* *display_uri* the URI the Client displays to the User to load in a
	browser to enter the code.		browser to enter the code.
	8. RS Access		6. RS Access
	This document specifies three different mechanisms for the Client to		The mechanism the Client MUST use to access an RS is in the
	access an RS ("bearer", "jose", and "jose+body"). The "bearer"		Authorization JSON "mechanism" attribute Section 4.4.4.
	mechanism is defined in {BearerToken}. The "jose" and "jose+body"
	mechanisms are proof-of-possession mechanisms and are defined in
	Section 10.2.2 and Section 10.2.3 respectively. Additional proof-of-
	possession mechanisms may be defined in other documents. The
	mechanism the Client is to use with an RS is the Response JSON
	authorization.mechanism attribute Section 6.4.4.
	8.1. Bearer Token		The "bearer" mechanism is defined in Section 2.1 of [RFC6750]
	If the access mechanism is "bearer", then the Client accesses the RS		The "jose" and "jose+body" mechanisms are defined in
	per Section 2.1 of [RFC6750]		[JOSE_Authentication]
	A non-normative example of the HTTP request headers follows:		A non-normative "bearer" example of the HTTP request headers follows:
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA		Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA
	9. Error Responses		7. Error Responses
	* TBD
	10. JOSE Authentication
	How the Client authenticates to the GS and RS are independent of each
	other. One mechanism can be used to authenticate to the GS, and a
	different mechanism to authenticate to the RS.
	Other documents that specify other Client authentication mechanisms
	will replace this section.
	In the JOSE Authentication Mechanism, the Client authenticates by
	using its private key to sign a JSON document with JWS per [RFC7515]
	which results in a token using JOSE compact serialization.
	[Editor: are there advantages to using JSON serialization in the
	body?]
	Different instances of a Registered Client MAY have different private
	keys, but each instance has a certificate to bind its private key to
	to a public key the GS has for the Client ID. An instance of a
	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
	TLS 1.3 ([RFC8446]) or later, when communicating with each other.
	[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
	body.
	The following sections specify how the Client uses JOSE to
	authenticate to the GS and RS.
	10.1. GS Access
	The Client authenticates to the GS by passing either a signed header
	parameter, or a signed message body. The following table shows the
	verb, uri and token location for each Client request to the GS:
	+---------------+-----------+-----------+----------+
	| request | http verb | uri | token in |
	+===============+===========+===========+==========+
	| Create Grant | POST | GS URI | body |
	+---------------+-----------+-----------+----------+
	| Verify Grant | PATCH | Grant URI | body |
	+---------------+-----------+-----------+----------+
	| Read Grant | GET | Grant URI | header |
	+---------------+-----------+-----------+----------+
	| Update Grant | PUT | Grant URI | body |
	+---------------+-----------+-----------+----------+
	| Delete Grant | DELETE | Grant URI | header |
	+---------------+-----------+-----------+----------+
	| Read AuthZ | GET | AZ URI | header |
	+---------------+-----------+-----------+----------+
	| Update AuthZ | PUT | AZ URI | body |
	+---------------+-----------+-----------+----------+
	| Delete AuthZ | DELETE | AZ URI | header |
	+---------------+-----------+-----------+----------+
	| GS Options | OPTIONS | GS URI | header |
	+---------------+-----------+-----------+----------+
	| Grant Options | OPTIONS | Grant URI | header |
	+---------------+-----------+-----------+----------+
	| AuthZ Options | OPTIONS | AZ URI | header |
	+---------------+-----------+-----------+----------+
	Table 2
	10.1.1. Authorization Header
	For requests with the token in the header, the JWS payload MUST
	contain the following attributes:
	*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.
	*uri* - the value of the URI being called (GS URI, Grant URI, or AZ
	URI).
	*verb* - the HTTP verb being used in the call ("GET", "DELETE",
	"OPTIONS")
	The HTTP authorization header is set to the "jose" parameter followed
	by one or more white space characters, followed by the resulting
	token.
	A non-normative example of a JWS payload and the HTTP request
	follows:
	{
	"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://as.example/endpoint/grant/example6",
	"verb" : "GET"
	}
	GET /endpoint/example.grant HTTP/2
	Host: as.example
	Authorization: jose eyJhbGciOiJIUzI1NiIsIn ...
	[Editor: make a real example token]
	*GS Verification*
	The GS MUST verify the token by:
	* TBD
	10.1.2. Signed Body
	For requests with the token in the body, the Client uses the Request
	JSON as the payload in a JWS. The resulting token is sent with the
	content-type set to "application/jose".
	A non-normative example (line breaks added to the body for
	readability):
	POST /endpoint HTTP/2
	Host: as.example
	Content-Type: application/jose
	Content-Length: 155
	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyzdWIiOiIxMjM0NTY3ODkwIiwibmF
	tZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMe
	Jf36POk6yJV_adQssw5c
	[Editor: make a real example token]
	*GS Verification*
	The GS MUST verify the token by:
	* TBD
	10.1.3. Public Key Resolution
	* *Registered Clients* can use any of the JWS header values to
	direct the GS to resolve the public key matching the private key
	used to the Client ID. The GS MAY restrict with JWS headers a
	Client can use.
	[Editor: would examples help here so that implementors understand the
	full range of options, and how an instance can have its own asymetric
	key pair]
	A non-normative example of a JOSE header for a Registered Client with
	a key identifier of "12":
	{
	"alg" : "ES256",
	"typ" : "JOSE",
	"kid" : "12"
	}
	* *Dynamic Clients* include their public key in the "jwk" JWS
	header.
	A non-normative example of a JOSE header for a Dynamic Client:
	{
	"alg" : "ES256",
	"typ" : "JOSE",
	"jwk" : {
	"kty" : "EC",
	"crv" : "P-256",
	"x" : "Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
	"y" : "GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
	}
	}
	10.2. RS Access
	In the "jose" mechanism Section 10.2.2, all Client requests to the RS
	include a proof-of-possession token in the HTTP authorization header.
	In the "jose+body" mechanism Section 10.2.3, the Client signs the
	JSON document in the request if the POST or PUT verbs are used,
	otherwise it is the same as the "jose" mechanism.
	10.2.1. JOSE header
	The GS provides the Client one or more JWS header parameters and
	values for a a certificate, or a reference to a certificate or
	certificate chain, that the RS can use to resolve the public key
	matching the private key being used by the Client.
	A non-normative examples JOSE header:
	{
	"alg" : "ES256",
	"typ" : "JOSE",
	"x5u" : "https://as.example/cert/example2"
	}
	[Editor: this enables Dynamic Clients to make proof-of-possession API
	calls the same as Registered Clients.]
	10.2.2. "jose" Mechanism
	The JWS payload MUST contain the following attributes:
	*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.
	*uri* - the value of the RS URI being called.
	*verb* - the HTTP verb being used in the call
	*token* - the access token provided by the GS to the Client
	The HTTP authorization header is set to the "jose" parameter followed
	by one or more white space characters, followed by the resulting
	token.
	A non-normative example of a JWS payload and the HTTP request
	follows:
	{
	"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://calendar.example/calendar",
	"verb" : "GET",
	"token" : "eyJJ2D6.example.access.token.mZf9pTSpA"
	}
	GET /calendar HTTP/2
	Host: calendar.example
	Authorization: jose eyJhbG.example.jose.token.adks
	[Editor: make a real example token]
	*RS Verification*
	The RS MUST verify the token by:
	* verify access token is bound to the public key - include key
	fingerprint in access token?
	* TBD		* TBD
	10.2.3. "jose+body" Mechanism		8. Warnings
	The "jose+body" mechanism can only be used if the content being sent
	to the RS is a JSON document.
	Any requests not sending a message body will use the "jose" mechanism
	Section 10.2.2.
	Requests sending a message body MUST have the following JWS payload:
	*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.
	*uri* - the value of the RS URI being called.
	*verb* - the HTTP verb being used in the call
	*token* - the access token provided by the GS to the Client
	*body* - the message body being sent to the RS
	A non-normative example of a JWS payload and the HTTP request
	follows:
	{
	"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://calendar.example/calendar",
	"verb" : "POST",
	"token" : "eyJJ2D6.example.access.token.mZf9pTSpA",
	"payload" : {
	"event" : {
	"title" : "meeting with joe",
	"start_date_utc" : "2020-02-21 11:00:00",
	"end_date_utc" : "2020-02-21 11:00:00"
	}
	}
	}
	POST /calendar HTTP/2
	Host: calendar.example
	Content-Type: application/jose
	Content-Length: 155
	eyJhbGciOi.example.jose+body.adasdQssw5c
	[Editor: make a real example token]
	*RS Verification*
	The RS MUST verify the token by:		Warnings assist a Client in detecting non-fatal errors.
	* TBD		* TBD
	10.2.4. Public Key Resolution		9. Extensibility
	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
	header.
	10.3. Request Encryption
	[Editor: to be fleshed out]
	The Client encrypts a request when ??? using the GS public key
	returned as the ??? attribute in GS Options Section 4.10.
	10.4. Response Signing
	[Editor: to be fleshed out]
	The Client verifies a signed response ??? using the GS public key
	returned as the ??? attribute in GS Options Section 4.10.
	10.5. Response Encryption
	[Editor: to be fleshed out]
	The Client decrypts a response when ??? using the private key
	matching the public key included in the request as the ??? attribute
	in Section 4.6.
	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]
	instead of JSON, and COSE [RFC8152] instead of JOSE, and CoAP		instead of JSON, and COSE [RFC8152] instead of JOSE, and CoAP
	[RFC8323] instead of HTTP/2.		[RFC8323] instead of HTTP/2.
	* *Grant*		* *Grant*
	- An extension can define new objects in the Grant Request and		- An extension can define new objects in the Grant Request and
	Grant Response JSON.		Grant Response JSON that return new URIs.
	* *Top Level*		* *Top Level*
	- Top level objects SHOULD only be defined to represent		- Top level objects SHOULD only be defined to represent
	functionality other the existing top level objects and		functionality other the existing top level objects and
	attributes.		attributes.
	* *"client" Object*		* *"client" Object*
	- Additional information about the Client that the GS would		- Additional information about the Client that the GS would
	skipping to change at page 46, line 49 ¶		skipping to change at page 27, line 4 ¶
	- Additional information about the Client that the GS would		- Additional information about the Client that the GS would
	require related to an extension.		require related to an extension.
	* *"user" Object*		* *"user" Object*
	- Additional information about the User that the GS would require		- Additional information about the User that the GS would require
	related to an extension.		related to an extension.
	* *"authorization" Object*		* *"authorization" Object*
	- Additional authorization schemas in addition to OAuth 2.0		- Additional authorization schemas in addition to OAuth 2.0
	scopes and RAR.		scopes and RAR.
	* *"claims" Object*		* *"claims" Object*
	- Additional claim schemas in addition to OpenID Connect claims		- Additional claim schemas in addition to OpenID Connect claims
	and Verified Credentials.		and Verified Credentials.
	* *interaction modes*		* *interaction modes*
	- Additional types of interactions a Client can start with the		- Additional types of interactions a Client can start with the
	User.		User.
	* *Continuous Authentication*		* *Continuous Authentication*
	- An extension could define a mechanism for the Client to		- An extension could define a mechanism for the Client to
	regularly provide continuous authentication signals and receive		regularly provide continuous authentication signals and receive
	responses.		responses.
	[Editor: do we specify access token / handle introspection in this		_[Editor: do we specify access token introspection in this document,
	document, or leave that to an extension?]		or leave that to an extension?]_
	[Editor: do we specify access token / handle revocation in this
	document, or leave that to an extension?]
	12. Rational
	1. *Why is there only one mechanism for the Client to authenticate
	with the GS? Why not support other mechanisms?*
	Having choices requires implementers to understand which choice
	is preferable for them. Having one default mechanism in the
	document for the Client to authenticate simplifies most
	implementations. Deployments that have unique characteristics
	can select other mechanisms that are preferable in specific
	environments.
	2. *Why is the default Client authentication JOSE rather than
	MTLS?*
	MTLS cannot be used today by a Dynamic Client. MTLS requires
	the application to have access below what is typically the
	application layer, that is often not available on some
	platforms. JOSE is done at the application layer. Many GS
	deployments will be an application behind a proxy performing
	TLS, and there are risks in the proxy passing on the results of
	MTLS.
	3. *Why is the default Client authentication JOSE rather than HTTP
	signing?*
	There is currently no widely deployed open standard for HTTP
	signing. Additionally, HTTP signing requires passing all the
	relevant parts of the HTTP request to downstream services within
	an GS that may need to independently verify the Client identity.
	4. *What are the advantages of using JOSE for the Client to
	authenticate to the GS and a resource?*
	Both Registered Clients and Dynamic Clients can have a private
	key, eliminating the public Client issues in OAuth 2.0, as a
	Dynamic Client can create an ephemeral key pair. Using
	asymetric cryptography also allows each instance of a Registered
	Client to have its own private key if it can obtain a
	certificate binding its public key to the public key the GS has
	for the Client. Signed tokens can be passed to downstream
	components in a GS or RS to enable independent verification of
	the Client and its request. The GS Initiated Sequence Section 5
	requires a URL safe parameter, and JOSE is URL safe.
	5. *Why does the GS not return parameters to the Client in the
	redirect url?*
	Passing parameters via a browser redirection is the source of
	many of the security risks in OAuth 2.0. It also presents a
	challenge for smart devices. In this protocol, the redirection
	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
	interaction control to the Client if the redirection was a full
	browser redirect. Unlike OAuth 2.0, the identity of the Client
	is independent of the URI the GS redirects to.
	6. *Why is there not a UserInfo endpoint as there is with OpenID
	Connect?*
	Since the Client can Read Grant at any time, it get the same
	functionality as the UserInfo endpoint, without the Client
	having to manage a separate access token and refresh token. If
	the Client would like additional claims, it can Update Grant,
	and the GS will let the Client know if an interaction is
	required to get any of the additional claims, which the Client
	can then start.
	[Editor: is there some other reason to have the UserInfo
	endpoint?]
	7. *Why is there still a Client ID?*
	The GS needs an identifier to fetch the meta data associated
	with a Client such as the name and image to display to the User,
	and the policies on what a Client is allowed to do. The Client
	ID was used in OAuth 2.0 for the same purpose, which simplifies
	migration. Dynamic Clients do not have a Client ID.
	8. *Why have both claims and authorizations?*
	There are use cases for each that are independent:		10. Rational
	authenticating a user and providing claims vs granting access to
	a resource. A request for an authorization returns an access
	token which may have full CRUD capabilities, while a request for
	a claim returns the claim about the User - with no create,
	update or delete capabilities. While the UserInfo endpoint in
	OIDC may be thought of as a resource, separating the concepts
	and how they are requested keeps each of them simpler in the
	Editor's opinion. :)
	9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and		1. *Why have both Client ID and Client Handle?*
	GS communication in ?*Section 10
	Knowing the GS supports HTTP/2 enables a Client to set up a		While they both refer to a Client in the protocol, the Client ID
	connection faster. HTTP/2 will be more efficient when Clients		refers to a pre-registered client,and the Client Handle is
	have large numbers of access tokens and are frequently		specific to an instance of a Dynamic Client. Using separate
	refreshing them at the GS as there will be less network traffic.		terms clearly differentiates which identifier is being presented
	Mandating TLS 1.3 similarly improves the performance and		to the GS.
	security of Clients and GS when setting up a TLS connection.
	10. *Why do some of the JSON objects only have one child, such as		2. *Why allow Client and GS to negotiate the user interaction mode?*
	the identifiers object in the user object in the Grant Request?*
	It is difficult to forecast future use cases. Having more		The Client knows what interaction modes it is capable of, and the
	resolution may mean the difference between a simple extension,		GS knows which interaction modes it will permit for a given Grant
	and a convoluted extension.		Request. The Client can then present the intersection to the
			User to choose which one is preferred. For example, while a
			device based Client may be willing to do both "indirect" and
			"user_code", a GS may not enable "indirect" for concern of a
			session fixation attack. Additional interaction modes will
			likely become available which allows new modes to be negotiated
			between Client and GS as each adds additional interaction modes.
	11. *Why is the "iss" included in the "oidc" identifier object?		3. *Why have both claims and authorizations?*
	Would the "sub" not be enough for the GS to identify the User?*		There are use cases for each that are independent: authenticating
			a user and providing claims vs granting access to a resource. A
			request for an authorization returns an access token which may
			have full CRUD capabilities, while a request for a claim returns
			the claim about the User - with no create, update or delete
			capabilities. While the UserInfo endpoint in OIDC may be thought
			of as a resource, separating the concepts and how they are
			requested keeps each of them simpler in the Editor's opinion. :)
	This decouples the GS from the OpenID Provider (OP). The GS		4. *Why do some of the JSON objects only have one child, such as the
	identifier is the GS URI, which is the endpoint at the GS. The		identifiers object in the user object in the Grant Request?*
	OP issuer identifier will likely not be the same as the GS URI.
	The GS may also provide claims from multiple OPs.
	12. *Why complicate things with interaction.keep?*		It is difficult to forecast future use cases. Having more
			resolution may mean the difference between a simple extension,
			and a convoluted extension. For example, the "global" object in
			the "interaction" object allows new global parameters to be added
			without impacting new interaction modes.
	The common sequence has a back and forth between the Client and		5. *Why is the "iss" included in the "oidc" identifier object?
	the GS, and the Client can update the Grant and have a new		Would the "sub" not be enough for the GS to identify the User?*
	interaction. Keeping the interaction provides a more seamless
	user experience where the results from the first request
	determine subsequent requests. For example, a common pattern is
	to use a GS to authenticate the User at the Client, and to
	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
	User, or a returning User. Asking a returning User to consent
	releasing claims they have already provided is a poor User
	experience, as is sending the User back to the GS. The Client
	requesting identity first enables the Client to get a response
	from the GS while the GS is still interacting with the User, so
	that the Client can request additional claims only if needed.
	Additionally, the claims a Client may want about a User may be
	dependent on some initial Claims. For example, if a User is in
	a particular country, additional or different Claims my be
	required by the Client.
	There are also benefits for the GS. Today, a GS usually keeps		This decouples the GS from the OpenID Provider (OP). The GS
	track of which claims a Client has requested for a User.		identifier is the GS URI, which is the endpoint at the GS. The
	Storing this information for all Clients a User uses may be		OP issuer identifier will likely not be the same as the GS URI.
	undesirable for a GS that does not want to have that information		The GS may also provide claims from multiple OPs.
	about the User. Keeping the interaction allows the Client to
	track what information it has about the User, and the GS can
	remain stateless.
	13. *Why is there a "jose+body" RS access mechanism method for the		6. *Why is there not a UserInfo endpoint as there is with OpenID
	Client?*Section 10.2.3		Connect?*
	There are numerous use cases where the RS wants non-repudiation		Since the Client can Read Grant at any time, it get the same
	and providence of the contents of an API call. For example, the		functionality as the UserInfo endpoint, without the Client having
	UGS Service Supplier Framework for Authentication and		to manage a separate access token and refresh token. If the
	Authorization [UTM].		Client would like additional claims, it can Update Grant, and the
			GS will let the Client know if an interaction is required to get
			any of the additional claims, which the Client can then start.
	14. *Why use URIs to instead of handles for the Grant and		_[Editor: is there some other reason to have the UserInfo
	Authorization?*		endpoint?]_
	A URI is an identifier just like a handle that can contain GS		7. *Why use URIs for the Grant and Authorization?*
	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
	manipulate a Grant or an Authorization. As the Grant URI and AZ
	URI are defined to start with the GS URI, the Client (and GS)
	can easily determine which GS a Grant or Authorization belong
	to. URIs also enable a RESTful interface to the GS
	functionality.
	15. *Why use the OPTIONS verb on the GS URI? Why not use a .well-		* Grant URI and AZ URI are defined to start with the GS URI,
	known mechanism?*		allowing the Client, and GS to determine which GS a Grant or
	Having the GS URI endpoint respond to the metadata allows the GS		Authorization belongs to.
	to provide Client specific results using the same Client
	authentication used for other requests to the GS. It also
	reduces the risk of a mismatch between what the advertised
	metadata, and the actual metadata. A .well-known discovery
	mechanism may be defined to resolve from a hostname to the GS
	URI.
	16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*		* URIs also enable a RESTful interface to the GS functionality.
	Maybe there are no use cases for them [that the editor knows		* A large scale GS can easily separate out the services that
	of], but the GS can not implement, and they are available if use		provide functionality as routing of requests can be done at
	cases come up.		the HTTP layer based on URI and HTTP verb. This allows a
			separation of concerns, independent deployment, and
			resiliency.
	17. *Why have both Client ID and Client Handle?*		8. *Why use the OPTIONS verb on the GS URI? Why not use a .well-
			known mechanism?*
	While they both refer to a Client in the protocol, the Client ID		Having the GS URI endpoint respond to the metadata allows the GS
	refers to a pre-registered client,and the Client Handle is		to provide Client specific results using the same Client
	specific to an instance of a Dynamic Client. Using separate		authentication used for other requests to the GS. It also
	terms clearly differentiates which identifier is being presented		reduces the risk of a mismatch between the advertised metadata,
	to the GS.		and the actual metadata. A .well-known discovery mechanism may
			be defined to resolve from a hostname to the GS URI.
	13. Acknowledgments		11. Acknowledgments
	This draft derives many of its concepts from Justin Richer's		This draft derives many of its concepts from Justin Richer's
	Transactional Authorization draft [TxAuth].		Transactional Authorization draft [TxAuth].
	Additional thanks to Justin Richer and Annabelle Richard Backman for		Additional thanks to Justin Richer and Annabelle Richard Backman for
	their strong critique of earlier drafts.		their strong critique of earlier drafts.
	14. IANA Considerations		12. IANA Considerations
	[ JOSE parameter for Authorization HTTP header ]
	TBD		TBD
	15. Security Considerations		13. Security Considerations
	TBD		TBD
	16. References		14. References
	16.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<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>.
	skipping to change at page 52, line 30 ¶		skipping to change at page 30, line 22 ¶
	[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,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <https://www.rfc-editor.org/info/rfc7515>.
	[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	RFC 7516, DOI 10.17487/RFC7516, May 2015,
	<https://www.rfc-editor.org/info/rfc7516>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.
	[OIDC] Sakimora, N., Bradley, J., Jones, M., de Medeiros, B., and		[OIDC] Sakimora, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0", November 2014,		C. Mortimore, "OpenID Connect Core 1.0", November 2014,
	<https://openiD.net/specs/openiD-connect-core-1_0.html>.		<https://openiD.net/specs/openiD-connect-core-1_0.html>.
	[OIDC4IA] Lodderstedt, T. and D. Fett, "OpenID Connect for Identity		[OIDC4IA] Lodderstedt, T. and D. Fett, "OpenID Connect for Identity
	Assurance 1.0", October 2019, <https://openid.net/specs/		Assurance 1.0", October 2019, <https://openid.net/specs/
	openid-connect-4-identity-assurance-1_0.html>.		openid-connect-4-identity-assurance-1_0.html>.
	16.2. Informative References		[RAR] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
			Rich Authorization Requests", January 2020,
			<https://tools.ietf.org/html/draft-ietf-oauth-rar-00>.
			[W3C_VC] Sporny, M., Noble, G., and D. Chadwick, "Verifiable
			Credentials Data Model 1.0", November 2019,
			<https://w3c.github.io/vc-data-model/>.
			[JOSE_Authentication]
			Hardt, D., "JOSE Authentication", June 2020,
			<https://tools.ietf.org/html/draft-hardt-gnap-jose>.
			[GNAP_Advanced]
			Hardt, D., "The Grant Negotiation and Authorization
			Protocol - Advanced Features", June 2020,
			<https://tools.ietf.org/html/draft-hardt-gnap-advanced>.
			14.2. Informative References
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
	<https://www.rfc-editor.org/info/rfc8252>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/info/rfc8323>.		<https://www.rfc-editor.org/info/rfc8323>.
	[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
	"OAuth 2.0 Device Authorization Grant", RFC 8628,
	DOI 10.17487/RFC8628, August 2019,
	<https://www.rfc-editor.org/info/rfc8628>.
	[browser_based_apps]		[browser_based_apps]
	Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based		Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based
	Apps", September 2019, <https://tools.ietf.org/html/draft-		Apps", September 2019, <https://tools.ietf.org/html/draft-
	ietf-oauth-browser-based-apps-04>.		ietf-oauth-browser-based-apps-04>.
	[RAR] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
	Rich Authorization Requests", January 2020,
	<https://tools.ietf.org/html/draft-ietf-oauth-rar-00>.
	[W3C_VC] Sporny, M., Noble, G., and D. Chadwick, "Verifiable
	Credentials Data Model 1.0", November 2019,
	<https://w3c.github.io/vc-data-model/>.
	[QR_Code] "ISO/IEC 18004:2015 - Information technology - Automatic		[QR_Code] "ISO/IEC 18004:2015 - Information technology - Automatic
	identification and data capture techniques - QR Code bar		identification and data capture techniques - QR Code bar
	code symbology specification", February 2015,		code symbology specification", February 2015,
	<https://www.iso.org/standard/62021.html>.		<https://www.iso.org/standard/62021.html>.
	[TxAuth] Richer, J., "Transactional AuthN", December 2019,		[TxAuth] Richer, J., "Transactional AuthN", December 2019,
	<https://tools.ietf.org/html/draft-richer-transactional-		<https://tools.ietf.org/html/draft-richer-transactional-
	authz-04>.		authz-04>.
	[UTM] Rios, J., Smith, I., and P. Venkatesen, "UGS Service
	Supplier Framework for Authentication and AuthN",
	September 2019, <https://utm.arc.nasa.gov/docs/2019-
	UTM_Framework-NGSA-TM220364.pdf>.
	Appendix A. Document History		Appendix A. Document History
	A.1. draft-hardt-xauth-protocol-00		A.1. draft-hardt-xauth-protocol-00
	* Initial version		* Initial version
	A.2. draft-hardt-xauth-protocol-01		A.2. draft-hardt-xauth-protocol-01
	* text clean up		* text clean up
	skipping to change at page 56, line 19 ¶		skipping to change at page 33, line 31 ¶
	* generation of client handle by GS for dynamic clients		* generation of client handle by GS for dynamic clients
	* renamed title to Grant Negotiation and Authorization Protocol.		* renamed title to Grant Negotiation and Authorization Protocol.
	Preserved draft-hardt-xauth-protocol filename to ease tracking		Preserved draft-hardt-xauth-protocol filename to ease tracking
	changes.		changes.
	* changed Authorizations to be key / value pairs (aka dictionary)		* changed Authorizations to be key / value pairs (aka dictionary)
	instead of a JSON array		instead of a JSON array
			A.9. draft-hardt-xauth-protocol-08
			* split document into three documents: core, advanced, and JOSE
			authentication.
			* grouped access granted into "access" object in Authorization JSON
			* added warnings object to the Grant Response JSON
	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 GNAP and OAuth 2.0 and OpenID Connect are:
	Connect are:
	* The Client allows uses a private key to authenticate in this		* The Client always uses a private asymetric key to authenticate to
	protocol instead of the client secret in OAuth 2.0 and OpenID		the GS. There is no client secret. i
	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, and optionally only receives an interaction nonce in the		the GS.
	redirection back from the GS.
	* The refresh_token has been replaced with a AZ URI that both		* The refresh_token has been replaced with a AZ URI that both
	represents the authorization, and is the URI for obtaining a fresh		represents the authorization, and is the URI for obtaining a fresh
	access token.		access token.
	* The Client can request identity claims to be returned independent		* The Client can request identity claims to be returned independent
	of the ID Token. There is no UserInfo endpoint to query claims as		of the ID Token. There is no UserInfo endpoint to query claims as
	there is in OpenID Connect.		there is in OpenID Connect.
	* The GS URI is the token endpoint.		* The GS URI is the token endpoint.
	*Preserved Features*		*Preserved Features*
	* This protocol reuses the OAuth 2.0 scopes, Client IDs, and access		* GNAP reuses the scopes, Client IDs, and access tokens of OAuth
	tokens of OAuth 2.0.		2.0.
	* This protocol reuses the Client IDs, Claims and ID Token of OpenID		* GNAP reuses the Client IDs, Claims and ID Token of OpenID Connect.
	Connect.
	* No change is required by the Client or the RS for accessing		* No change is required by the Client or the RS for accessing
	existing bearer token protected APIs.		existing bearer token protected APIs.
	*New Features*		*New Features*
			* All Client calls to the GS are authenticated with asymetric
			cryptography
	* A Grant represents both the user identity claims and RS access		* A Grant represents both the user identity claims and RS access
	granted to the Client.		granted to the Client.
	* The Client can verify, update, retrieve, and delete a Grant.
	* The GS can initiate a flow by creating a Grant and redirecting the
	User to the Client with the Grant URI.
	* The Client can discovery if a GS has a User with an identifier
	before the GS interacts with the User.
	* The Client can request the GS to first authenticate the User and
	return User identity claims, and then the Client can update Grant
	request based on the User identity.
	* Support for scannable code initiated interactions.		* Support for scannable code initiated interactions.
	* Each Client instance can have its own private / public key pair.		* Highly extensible per Section 9.
	* Highly extensible per Section 11.
	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. 238 change blocks.
	1580 lines changed or deleted		541 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/