< draft-hardt-xauth-protocol-00.txt		draft-hardt-xauth-protocol-01.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 27 January 2020		Intended status: Standards Track 29 January 2020
	Expires: 30 July 2020		Expires: 1 August 2020
	The XAuth Protocol		The XAuth Protocol
	draft-hardt-xauth-protocol-00		draft-hardt-xauth-protocol-01
	Abstract		Abstract
	Client software often desires resources or identity claims that are		Client software often desires resources or identity claims that are
	managed independent of the client. This protocol allows a user and/		managed independent of the client. This protocol allows a user and/
	or resource owner to delegate resource authorization and/or release		or resource owner to delegate resource authorization and/or release
	of identity claims to an authorization server. Client software can		of identity claims to an authorization server. Client software can
	then request access to resources and/or identity claims by calling		then request access to resources and/or identity claims by calling
	the authorization server. The authorization server acquires consent		the authorization server. The authorization server acquires consent
	and authorization from the user and/or resource owner if required,		and authorization from the user and/or resource owner if required,
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 30 July 2020.		This Internet-Draft will expire on 1 August 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Handles . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Handles . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Initiation Request JSON . . . . . . . . . . . . . . . . . . . 7		3. AS Request JSON . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 9		3.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 11
	3.2. "client" Object . . . . . . . . . . . . . . . . . . . . . 9		3.2. "client" Object . . . . . . . . . . . . . . . . . . . . . 11
	3.3. "user" Object . . . . . . . . . . . . . . . . . . . . . . 11		3.3. "user" Object . . . . . . . . . . . . . . . . . . . . . . 12
	3.4. "authorizations" Object . . . . . . . . . . . . . . . . . 11		3.4. "authentication" Object . . . . . . . . . . . . . . . . . 13
	3.5. "claims" Object . . . . . . . . . . . . . . . . . . . . . 12		3.5. "authorizations" Object . . . . . . . . . . . . . . . . . 13
	3.6. Authorization Types . . . . . . . . . . . . . . . . . . . 12		3.6. "claims" Object . . . . . . . . . . . . . . . . . . . . . 14
	4. Initiation Response JSON . . . . . . . . . . . . . . . . . . 12		3.7. Authorization Types . . . . . . . . . . . . . . . . . . . 14
	4.1. "user" Object . . . . . . . . . . . . . . . . . . . . . . 13		4. Interaction Response JSON . . . . . . . . . . . . . . . . . . 14
	4.2. "interaction" Object . . . . . . . . . . . . . . . . . . 13		4.1. "user" Object . . . . . . . . . . . . . . . . . . . . . . 15
	4.3. "completion" Object . . . . . . . . . . . . . . . . . . . 14		4.2. "interaction" Object . . . . . . . . . . . . . . . . . . 15
	5. Interaction Types . . . . . . . . . . . . . . . . . . . . . . 14		4.3. "authorization" Object . . . . . . . . . . . . . . . . . 16
	5.1. "popup" Type . . . . . . . . . . . . . . . . . . . . . . 14		4.4. "authentication" Object . . . . . . . . . . . . . . . . . 16
	5.2. "redirect" Type . . . . . . . . . . . . . . . . . . . . . 14		5. Interaction Types . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. "qrcode" Type . . . . . . . . . . . . . . . . . . . . . . 15		5.1. "popup" Type . . . . . . . . . . . . . . . . . . . . . . 16
	6. Completion Response JSON . . . . . . . . . . . . . . . . . . 15		5.2. "redirect" Type . . . . . . . . . . . . . . . . . . . . . 17
	6.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 16		5.3. "qrcode" Type . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. "authorizations" Object . . . . . . . . . . . . . . . . . 16		6. AS Response JSON . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. "claims" Object . . . . . . . . . . . . . . . . . . . . . 17		6.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 18
	6.4. Access Types . . . . . . . . . . . . . . . . . . . . . . 18		6.2. "authorizations" Object . . . . . . . . . . . . . . . . . 18
	7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 18		6.3. "claims" Object . . . . . . . . . . . . . . . . . . . . . 19
	8. JOSE Client Authentication . . . . . . . . . . . . . . . . . 18		6.4. Access Methods . . . . . . . . . . . . . . . . . . . . . 20
	8.1. JOSE Headers . . . . . . . . . . . . . . . . . . . . . . 19		7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	8.2. JOSE Completion Token . . . . . . . . . . . . . . . . . . 21		8. JOSE Client Authentication . . . . . . . . . . . . . . . . . 20
	8.3. JOSE Refresh Token . . . . . . . . . . . . . . . . . . . 22		8.1. JOSE Headers . . . . . . . . . . . . . . . . . . . . . . 21
	8.4. JOSE Access Token . . . . . . . . . . . . . . . . . . . . 23		8.2. Authentication Request Token . . . . . . . . . . . . . . 23
	8.5. HTTP Authorization JOSE Header . . . . . . . . . . . . . 23		8.3. Authorization Request Token . . . . . . . . . . . . . . . 24
	8.6. JOSE Token Verification . . . . . . . . . . . . . . . . . 23		8.4. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 25
	8.7. Initiation Request . . . . . . . . . . . . . . . . . . . 23		8.5. JOSE Access Token . . . . . . . . . . . . . . . . . . . . 25
	8.8. Initiation Response . . . . . . . . . . . . . . . . . . . 24		8.6. HTTP Authorization JOSE Header . . . . . . . . . . . . . 26
	8.9. Deletion Request . . . . . . . . . . . . . . . . . . . . 24		8.7. JOSE Token Verification . . . . . . . . . . . . . . . . . 26
	8.10. Completion Request . . . . . . . . . . . . . . . . . . . 24		8.8. AS Request . . . . . . . . . . . . . . . . . . . . . . . 26
	8.11. Completion Response . . . . . . . . . . . . . . . . . . . 25		8.9. Interaction Response . . . . . . . . . . . . . . . . . . 26
	8.12. Bearer Token RS Access . . . . . . . . . . . . . . . . . 25		8.10. Deletion Request . . . . . . . . . . . . . . . . . . . . 27
	8.13. Proof-of-possession RS Access . . . . . . . . . . . . . . 26		8.11. Authentication Request . . . . . . . . . . . . . . . . . 27
	8.14. Access Refresh . . . . . . . . . . . . . . . . . . . . . 26		8.12. Authentication Response . . . . . . . . . . . . . . . . . 27
	9. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 27		8.13. Authorization Request . . . . . . . . . . . . . . . . . . 27
	10. AS Initiated Sequence . . . . . . . . . . . . . . . . . . . . 27		8.14. AS Response . . . . . . . . . . . . . . . . . . . . . . . 28
	10.1. Initiation Token . . . . . . . . . . . . . . . . . . . . 28		8.15. Bearer Token RS Access . . . . . . . . . . . . . . . . . 28
	11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29		8.16. Proof-of-possession RS Access . . . . . . . . . . . . . . 29
	12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 30		8.17. JOSE Body RS Access . . . . . . . . . . . . . . . . . . . 29
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		8.18. Access Refresh . . . . . . . . . . . . . . . . . . . . . 29
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 30
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 32		10. AS Initiated Sequence . . . . . . . . . . . . . . . . . . . . 30
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.1. Initiation Token . . . . . . . . . . . . . . . . . . . . 32
	16.1. Normative References . . . . . . . . . . . . . . . . . . 33		11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 32
	16.2. Informative References . . . . . . . . . . . . . . . . . 34		12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 35		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 35		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 35		15. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
			16.1. Normative References . . . . . . . . . . . . . . . . . . 36
			16.2. Informative References . . . . . . . . . . . . . . . . . 38
			Appendix A. Document History . . . . . . . . . . . . . . . . . . 39
			A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 39
			A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 39
			Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 39
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	This protocol supports the widely deployed use cases supported by		This protocol supports the widely deployed use cases supported by
	OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an		OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an
	extension of OAuth 2.0, as well as other extensions, and other use		extension of OAuth 2.0, as well as other extensions, and other use
	cases that are not supported, such as requesting multiple		cases that are not supported, such as requesting multiple
	authorizations in one request. This protocol also addresses many of		authorizations in one request. This protocol also addresses many of
	the security issues in OAuth 2.0 by having parameters securely sent		the security issues in OAuth 2.0 by having parameters securely sent
	directly between parties, rather than via a browser redirection.		directly between parties, rather than via a browser redirection.
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 18 ¶
	2.0: OpenID Connect added support for authentication and releasing		2.0: OpenID Connect added support for authentication and releasing
	identity claims; [RFC8252] added support for native apps; [RFC8628]		identity claims; [RFC8252] added support for native apps; [RFC8628]
	added support for smart devices; and support for [browser_based_apps]		added support for smart devices; and support for [browser_based_apps]
	is being worked on. There are numerous efforts on adding proof-of-		is being worked on. There are numerous efforts on adding proof-of-
	possession to resource access.		possession to resource access.
	This protocol simplifies the overall architectural model, takes		This protocol simplifies the overall architectural model, takes
	advantage of today's technology landscape, provides support for all		advantage of today's technology landscape, provides support for all
	the widely deployed use cases, and offers numerous extension points.		the widely deployed use cases, and offers numerous extension points.
			The
	While this protocol is not backwards compatible with OAuth 2.0, it		While this protocol is not backwards compatible with OAuth 2.0, it
	strives to minimize the migration effort.		strives to minimize the migration effort.
	2. Protocol		2. Protocol
	2.1. Parties		2.1. Parties
	* *Authorization Server* (AS) - manages Client authorization to API		* *Authorization Server* (AS) - manages Client authorization to API
	resources and release of identity claims about the User. The AS		resources and release of identity claims about the User. The AS
	may require explicit consent from the RO or User to provide these		may require explicit consent from the RO or User to provide these
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 15 ¶
	* *Resource Server* (RS) - has API resources that require an access		* *Resource Server* (RS) - has API resources that require an access
	token from the AS for access.		token from the AS for access.
	* *Resource Owner* (RO) - owns the RS, and has delegated RS access		* *Resource Owner* (RO) - owns the RS, and has delegated RS access
	token creation to the AS. The RO may be the same entity as the		token creation to the AS. The RO may be the same entity as the
	User, or may be a different entity that the AS interacts with		User, or may be a different entity that the AS interacts with
	independent of the Client.		independent of the Client.
	2.2. Handles		2.2. Handles
	Handles are strings issued by the AS to the Client, that are opaque		Handles are strings issued by the AS to the Client that are opaque to
	to the Client.		the Client.
	* *completion handle* - represents the client request. Presented		* *authorization handle* - represents the client request. Presented
	back to the AS in a completion request.		back to the AS in an Authorization Request.
			* *authentication handle* - represents the client request for
			authentication first. Presented back to the AS in an
			Authentication Request, or in the subsequent AS Request.
	* *access handle* - represents the access the AS has granted the		* *access handle* - represents the access the AS has granted the
	Client to the RS. The Client proves possession of its key when		Client to the RS. The Client proves possession of its key when
	presenting an access handle to access an RS. The RS is able to		presenting an access handle to access an RS. The RS is able to
	understand the authorizations represented by the access handle		understand the authorizations represented by the access handle
	directly, or through an introspection call. The RS is able to		directly, or through an introspection call. The RS is able to
	verify the access handle was issued to the Client that presented		verify the access handle was issued to the Client that presented
	it.		it.
	* *refresh handle* - represents the access the AS has granted the		* *refresh handle* - represents the access the AS has granted the
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 52 ¶
	* *access token* - an access token as defined in [RFC6749]		* *access token* - an access token as defined in [RFC6749]
	Section 1.4.		Section 1.4.
	* *Claims* - Claims as defined in [OIDC] Section 5.		* *Claims* - Claims as defined in [OIDC] Section 5.
	* *Client ID* - an AS unique identifier for a Registered Client as		* *Client ID* - an AS unique identifier for a Registered Client as
	defined in [RFC6749] Section 2.2.		defined in [RFC6749] Section 2.2.
	* *ID Token* - an ID Token as defined in [OIDC] Section 2.		* *ID Token* - an ID Token as defined in [OIDC] Section 2.
	* *Claims* - Claims as defined in [OIDC] Section 5.
	* *NumericDate* - a NumericDate as defined in [RFC7519] Section 2.		* *NumericDate* - a NumericDate as defined in [RFC7519] Section 2.
	2.4. Sequence		2.4. Sequence
	1. *AS Discovery* The Client discovers the AS end point, keys,		1. *AS Discovery* (Section 7) The Client discovers the AS end
	supported claims and authorizations, and other capabilities.		point, keys, supported claims and authorizations, and other
	Some, or all of this information could be manually preconfigured,		capabilities. Some, or all of this information could be
	or dynamically obtained. Dynamic AS discovery is out of scope of		manually preconfigured, or dynamically obtained. Dynamic AS
	this document.		discovery is out of scope of this document.
	2. *Initiation Request* (Section 8.7) The Client creates an		2. *AS Request* (Section 8.8) The Client creates an AS Request
	initiation request (Section 3) for authorization to API resources		(Section 3) for authorization to API resources and/or identity
	and/or identity claims about the User and sends it with an HTTP		claims about the User and sends it with an HTTP POST to the AS
	POST to the AS endpoint.		endpoint. The Client includes requests authentication first if
			the Client wants the AS to authenticate the User prior to
			requesting additional claims and authorizations.
	3. *Initiation Response* (Section 8.8) The AS processes the request		3. *AS Request Evaluation* The AS processes the request and
	and determines if it needs to interact with the RO or User. If		determines if it needs to interact with the RO or User. If
	interaction is not required, the AS returns a completion response		interaction is required, the AS returns an Interaction Response
	(Section 6). If interaction is required the AS returns an		(Section 4), if no interaction is required it returns an AS
	initiation response (Section 4) that includes completion handle		Response (Section 6).
	and uri, and interaction instructions if the AS wants the Client
	to start the interaction.
	4. *Interaction* (Section 5) If the AS sent interaction instructions		4. *Interaction Response* (Section 8.9) The AS will send an
	to the Client, the Client executes them. The AS then interacts		authentication object unless the Client sent authentication
	with the User and/or RO to obtain authorization. The AS		first, in which case the AS will send an authentication object.
	interaction with an RO may be asynchronous, and take time to		If the AS wants the Client to initiate the User interaction, it
	complete.		will include an interaction object. If authentication first,
			the Client will next send (6) Authentication Request, otherwise
			an Authorization Request.
	5. *Completion Request* (Section 8.10) The Client sends the		5. *Authorization Request* (Section 8.13) The Client creates an
	completion handle to the completion uri. The Client may make the		authorization request token Section 8.3 and does a GET of the
	completion request while waiting for the interaction to complete.		authorization uri, after waiting for any authorization wait
			time. The Client then listens for (13) AS Response.
	6. *Completion Response* (Section 8.11) When any required		6. *Authentication Request* (Section 8.11) The Client creates an
	interaction has been completed, the AS responds to the Client		authentication request token and does a GET of the
	with a completion response (Section 6) containing authorized RS		authentication uri. The Client then listens for (9)
	access tokens and User identity claims. The AS may provide		Authentication Response.
	refresh handles and uris for each access token if they are
	authorized. If proof-of-possession is required for accessing the
	RS, the AS will provide access handles instead of access tokens.
	If the AS has not completed the interaction, it will return a
	retry response for the Client to make a new completion request.
	7. *Resource Request* (Section 8.12 & Section 8.13) The Client uses		7. *Interaction* If the AS sent interaction instructions to the
	an access token with the RS, or the access handle if proof-of-		Client, the Client executes them.
	possession is required for access.
	8. *Access Refresh* (Section 8.14) If the Client received a refresh		8. *User Authentication* The AS authenticates the User. If Client
	handle and uri, it sends the refresh handle to the refresh uri,		requested authentication first, the AS responds to the
	and receives a fresh access token or handle.		Authentication Request with an (9) Authentication Response,
			otherwise the AS performs any needed authorizations per step
			(10).
			9. *Authentication Response* (Section 8.12) The AS sends an AS
			Response containing the identity claims the Client requested.
			10. *AS Request 2* The Client uses the returned identity claims to
			look up the User in its internal database and determines what,
			if any, claims and/or authorizations it would like to request
			and includes them in a new AS Request, as well as the
			authentication handle. If Client wants not additional claims
			and/or authorizations, the Client sets the claims object to the
			JSON null value. The Client then listens for (13) AS Response.
			11. *Authorization* If required, the AS interacts with the User and/
			or RO to determine which of any of the authorizations and
			identity claims requests made by the Client are to be granted.
			12. *Redirect* If the Client did a full browser redirect to the AS,
			the AS redirects the User back to the redirect_uri supplied by
			the Client, otherwise the AS closes its popup window, or informs
			the User the interaction is complete.
			13. *AS Response* (Section 8.14) The AS responds to the Client with
			a AS Response (Section 6) containing authorized RS access tokens
			and User identity claims. The AS may provide refresh handles
			and uris for each access token if they are authorized. If
			proof-of-possession is required for accessing the RS, the AS
			will provide access handles instead of access tokens. If the AS
			has not completed the interaction, it will instead return a
			retry response for the Client to make a new Authorization
			Request.
			14. *Resource Request* (Section 8.15, Section 8.16, & Section 8.17)
			The Client access the RS using a bearer token, a proof-of-
			possession token, or a signed request.
			15. *Access Refresh* (Section 8.18) If the Client received a refresh
			handle and uri, it sends the refresh handle to the refresh uri,
			and receives a fresh access token or handle.
	*Sequence Diagram*		*Sequence Diagram*
	+--------+ +---------------+		+--------+ +---------------+
	| |<-(1)------- Discovery ------------------->| |		| |<-(1)------- Discovery ------------------->| Authorization |
	| | | |		| | | Server |
	| |--(2)------- Initiation Request ---------->| |		| |--(2)------- AS Request ------------------>| |
	| | | |		| | | (3) Request |
	| |<-(3)------- Initiation Response-----------| |		| | | Evaluation |
	| | | |		| |<-(4)------- Interaction Response ---------| |
	| | +-Interaction-+ | |
	| |--(4)-------->| User |<-------------| |
	| | | and/or RO |<-------------| |
	| | +-------------+ | Authorization |
	| Client | | Server |
	| |--(5)------- Completion Request ---------->| |
	| | | |
	| |<-(6)------- Completion Response ----------| |
	| | | |		| | | |
	| | +----------+ | |		| |--(5)------- Authorization Request ------->| -------+ |
	| |--(7)-- Resource Request -->| Resource | | |		| | or | | |
	| | | Server | | |		| |--(6)------- Authentication Request ------>| ---+ | |
	| |<------ Resource Response --| | | |		| | | | | |
	| | +----------+ | |		| | +--------+ | | | |
			| |--(7)--------->| User |<------------(8)--| | | |
			| | Interaction +--------+ Authentication | | | |
			| Client | | | | |
			| | | | | |
			| |<-(9)------- Authentication Response ------|<---+ | |
			| | | | |
			| |--(10)------ AS Request 2 ---------------->| -------+ |
			| | | | |
			| | +--------+ | | |
			| |<-(12)---------| User |<-----------(11)--| | |
			| | Redirect | / RO | Authorization | | |
			| | +--------+ | | |
			| | | | |
			| |<-(13)------ AS Response ------------------|<-------+ |
	| | | |		| | | |
	| |--(8)------- Refresh Request ------------->| |		| | +----------+ | |
			| |--(14)-- Resource Request -->| Resource | | |
			| |<------ Resource Response ---| Server | | |
			| | +----------+ | |
	| | | |		| | | |
			| |--(15)------- Refresh Request ------------>| |
	| |<----------- Refresh Response -------------| |		| |<----------- Refresh Response -------------| |
	+--------+ +---------------+		+--------+ +---------------+
	3. Initiation Request JSON		3. AS Request JSON
	Following is a non-normative JSON [RFC8259] document example where		Following is a non-normative JSON [RFC8259] document example where
	the Client wants to interact with the User with a popup and is		the Client wants to interact with the User with a popup and is
	requesting identity claims about the User and read access to the		requesting identity claims about the User and read access to the
	User's contacts:		User's contacts:
	Example 1		Example 1
	{		{
	"as" :"https://as.example",		"as" :"https://as.example",
	skipping to change at page 9, line 8 ¶		skipping to change at page 10, line 8 ¶
	}		}
	}		}
	}		}
	Following is a non-normative example where the Client has previously		Following is a non-normative example where the Client has previously
	authenticated the User, and is requesting additional authorization:		authenticated the User, and is requesting additional authorization:
	Example 2		Example 2
	{		{
	"as" :"https://as.example",		"as" :"https://as.example",
	"iat" :"1579046092",		"iat" :"1579046092",
	"nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"client": {		"client": {
	"id" : "di3872h34dkJW",		"id" : "di3872h34dkJW",
	"interaction": {		"interaction": {
	"type" : "redirect",		"type" : "redirect",
	"uri" : "https://web.example/return"		"uri" : "https://web.example/return"
	}		}
	},		},
	"user": {		"user": {
	skipping to change at page 9, line 32 ¶		skipping to change at page 10, line 32 ¶
	"sub" :"123456789"		"sub" :"123456789"
	}		}
	}		}
	},		},
	"authorizations": {		"authorizations": {
	"type" :"oauth_scope",		"type" :"oauth_scope",
	"scope" :"read_calendar write_calendar"		"scope" :"read_calendar write_calendar"
	}		}
	}		}
			Following is a non-normative example where the Client is requesting
			authorization first:
			Example 3
			{
			"as" :"https://as.example",
			"iat" :"1579046092",
			"nonce" :"5c9360a5-9065-4f7b-a330-5713909e06c6",
			"client": {
			"id" : "di3872h34dkJW",
			"interaction": {
			"type" : "redirect",
			"uri" : "https://web.example/return"
			}
			},
			"authentication": {
			"first": true
			},
			"claims": { "oidc": { "id_token" : {} } }
			}
			Following is a non-normative example where the Client previously
			requested authorization first (Example 3), the response was a new
			User, and now makes the following AS Request:
			Example 4
			{
			"as" :"https://as.example",
			"iat" :"1579046092",
			"nonce" :"0a74f51f-514a-4821-b71f-01c252223f2f",
			"authentication": {
			"handle": "eyJhb958.example.authentication.handle.9yf3szM"
			},
			"claims": {
			"oidc": {
			"userinfo" : {
			"email" : { "essential" : true },
			"phone_number" : { "essential" : true },
			"name" : { "essential" : true },
			"picture" : null
			}
			}
			}
			}
	3.1. Top Level Attributes		3.1. Top Level Attributes
	*as* - the unique string identifier for the AS. This attribute is		*as* - the unique string identifier for the AS. This attribute is
	REQUIRED.		REQUIRED.
	*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. This attribute is		*nonce* - a unique identifier for this request. This attribute is
	REQUIRED. Note the completion response MUST contain a matching nonce		REQUIRED. Note the AS Response MUST contain a matching nonce
	attribute.		attribute.
	3.2. "client" Object		3.2. "client" Object
	The client object MUST contain either the client_id attribute for		The client object MUST contain either the client_id attribute for
	Registered Clients, or the display object for Dynamic Clients. If		Registered Clients, or the display object for Dynamic Clients. If
	the Client can interact with the User, then an interaction object		the Client can interact with the User, then an interaction object
	MUST be included.		MUST be included. If there is an authentication handle, then the
			client object MUST not be included.
	*client_id* - the identifier the AS has for the Registered Client.		*client_id* - the identifier the AS has for the Registered Client.
	*display* - the display object contains the following attributes:		*display* - the display object contains the following attributes:
	* *name* - a string that represents the Dynamic Client		* *name* - a string that represents the Dynamic Client
	[Editor: a max length for the name?]		[Editor: a max length for the name?]
	* *uri* - a URI representing the Dynamic Client		* *uri* - a URI representing the Dynamic Client
	[Editor: a max length for the name?]		[Editor: a max length for the URI?]
	The name and uri will be displayed by the AS when prompting for		The name and uri will be displayed by the AS when prompting for
	authorization.		authorization.
	*interaction* - the interaction object contains the type of		*interaction* - the interaction object contains the type of
	interaction the Client will provide the User. Other attributes are		interaction the Client will provide the User. Other attributes are
	dependent on the interaction type value.		dependent on the interaction type value.
	* *type* - contains one of the following values. Types are listed		* *type* - contains one of the following values: "popup",
	from highest to lowest fidelity. The interaction URI is the value		"redirect", or "qrcode". Details in Section 5.
	returned by the AS in the initiation response interaction object
	Section 4.2, if a User interaction is required by the AS.
	- *popup* - the Client will load the interaction URI in a modal
	popup window. The AS will close the window when the
	interaction is complete.
	- *redirect* - the Client will redirect the user agent to the
	interaction URI provided by the AS. The AS will redirect to
	the redirect_uri when the interaction is completed.
	- *qrcode* - the Client will convert the interaction URI to a QR
	Code per [QR_Code] and display it to the User, along with a
	text message. The User will scan the QR Code and/or follow the
	message instructions.
	* *redirect_uri* - this attribute is included if the type is		* *redirect_uri* - this attribute is included if the type is
	"redirect". It is the URI that the Client requests the AS to		"redirect". It is the URI that the Client requests the AS to
	redirect the User to after the AS has completed interacting with		redirect the User to after the AS has completed interacting with
	the User. If the Client manages session state in URIs, then the		the User. If the Client manages session state in URIs, then the
	redirect_uri should contain that state.		redirect_uri should contain that state.
	* *ui_locales* - End-User's preferred languages and scripts for the		* *ui_locales* - End-User's preferred languages and scripts for the
	user interface, represented as a space-separated list of [RFC5646]		user interface, represented as a space-separated list of [RFC5646]
	language tag values, ordered by preference.		language tag values, ordered by preference.
	skipping to change at page 11, line 10 ¶		skipping to change at page 12, line 43 ¶
	[Editor: do we need max pixels or max chars for qrcode interaction?		[Editor: do we need max pixels or max chars for qrcode interaction?
	Either passed to AS, or max specified values here?]		Either passed to AS, or max specified values here?]
	[Editor: other possible interaction models could be a "webview",		[Editor: other possible interaction models could be a "webview",
	where the Client can display a web page, or just a "message", where		where the Client can display a web page, or just a "message", where
	the client can only display a text message]		the client can only display a text message]
	[Editor: we may need to include interaction types for iOS and Android		[Editor: we may need to include interaction types for iOS and Android
	as the mobile OS APIs evolve.]		as the mobile OS APIs evolve.]
	[Editor: does the Client include parameters if it wants the		[Editor: does the Client include parameters if it wants the AS
	completion response signed and/or encrypted?]		Response signed and/or encrypted?]
	3.3. "user" Object		3.3. "user" Object
	The user object is optional.		The user object is optional.
	*identifiers* - the identifiers object contains one or more of the		*identifiers* - the identifiers object 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 per [OIDC] Section 2.		attributes from an OpenID Connect ID Token per [OIDC] Section 2.
	The user and identifiers objects MAY be included to improve the user		The user and identifiers objects MAY be included to improve the user
	experience by the AS. The AS MUST authenticate the User independent		experience by the AS. The AS MUST authenticate the User independent
	of these values.		of these values. The user object MUST not be included if there is an
			authentication handle.
	*discovery* - MUST contain the JSON true value. Indicates the Client		*discovery* - MUST contain the JSON true value. Indicates the Client
	requests the AS to return a "discovered" attribute in the initiation		requests the AS to return a "discovered" attribute in the Interaction
	response if the AS has a User at the AS with one or more of the		Response if the AS has a User at the AS with one or more of the
	identifiers. This attribute is OPTIONAL. Supporting by the AS of		identifiers. This attribute is OPTIONAL. Support of the discovery
	the discovery attribute is OPTIONAL. The AS MAY return the TBD error		attribute by the AS is OPTIONAL. The AS MAY return the [TBD] error
	if discovery is not supported, or ignore the request.		if discovery is not supported, or ignore the request.
	3.4. "authorizations" Object		3.4. "authentication" Object
			This OPTIONAL object MUST contain one of the following attributes:
			* *first* - Must have the JSON value true. Indicates the Client is
			requesting authentication first, and an authentication object in
			the Interaction Response. If present, the AS will ignore the
			authorizations object. [Editor: any use case where the Client
			needs an authorization at Authentication?] The Client SHOULD
			limit the claims requested to only those needed to identify the
			User at the Client. [Editor: this works if it is only a directed
			identifier, but consent would be required to return a verified
			phone or email. Hmmm.]
			* *handle* - the authentication handle. MUST be included in the AS
			Request following an Authentication Response.
			3.5. "authorizations" Object
	The optional authorizations object contains a dictionary of resource		The optional authorizations object contains a dictionary of resource
	objects the Client is requesting authorization to access. The		objects the Client is requesting authorization to access. The
	authorizations object may contain one or more of:		authorizations object may contain one or more of:
	* *type* - one of the following values: "oauth_scope", "oauth_rich",		* *type* - one of the following values: "oauth_scope", "oauth_rich",
	or "oauth_rich_list". See Section 3.6 for details.		or "oauth_rich_list". See Section 3.7 for details.
	* *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. Present if type is "oauth_scope" or "oauth_rich".		section 3.3. Present if type is "oauth_scope" or "oauth_rich".
	* *authorization_details* - an authorization_details object per		* *authorization_details* - an authorization_details object per
	[RAR]. Present if type is "oauth_rich".		[RAR]. Present if type is "oauth_rich".
	* *list* - an array of objects containing "scope" and		* *list* - an array of objects containing "scope" and
	"authorization_details". Present if type is "oauth_rich_list".		"authorization_details". Present if type is "oauth_rich_list".
	Used when requesting multiple access tokens and/or handles.		Used when requesting multiple access tokens and/or handles.
	[Editor: details may change as the [RAR] document evolves]		[Editor: details may change as the [RAR] document evolves]
	3.5. "claims" Object		3.6. "claims" Object
	The optional claims object contains one or more identity claims being		The optional claims object contains one or more identity claims being
	requested. The claims may contain:		requested. The claims may contain:
	* *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.
	* vc - [Editor: define how W3C Verifiable Credentials [W3C_VC] can		* *oidc4ia* - OpenID Connect for Identity Assurance claims request
			per [OIDC4IA].
			* *vc* - [Editor: define how W3C Verifiable Credentials [W3C_VC] can
	be requested.]		be requested.]
	3.6. Authorization Types		3.7. Authorization Types
	* *oauth_scope* - an OAuth 2.0 authorization request per [RFC6749]		* *oauth_scope* - an OAuth 2.0 authorization request per [RFC6749]
	section 3.3		section 3.3
	* *oauth_rich* - a rich authorization request per [RAR]		* *oauth_rich* - a rich authorization request per [RAR]
	* *oauth_rich_list* - a list of rich authorization requests		* *oauth_rich_list* - a list of rich authorization requests
	4. Initiation Response JSON		4. Interaction Response JSON
	A non-normative example of an initiation response follows:		A non-normative example of an Interaction Response follows:
	{		{
	"user": {		"user": {
	"discovered": true		"discovered": true
	},		},
	"interaction": {		"interaction": {
	"type" : "popup",		"type" : "popup",
	"uri" : "https://as.example/endpoint/ey5gs32..."		"uri" : "https://as.example/endpoint/ey5gs32..."
	},		},
	"completion": {		"authorization": {
	"handle" : "eyJhb958.example.completion.handle.9yf3szM",		"handle" : "eyJhb958.example.authorization.handle.9yf3szM",
	"uri" : "https://as.example/completion/ey7snHGs",		"uri" : "https://as.example/authorization/ey7snHGs",
	"wait" : "10"		"wait" : "10"
	}		}
	}		}
	4.1. "user" Object		4.1. "user" Object
	If the initiation request included a discovery attribute, then the AS		MUST contain one of "authorization" object, or "authentication"
	MAY return a "user" object with the "discovered" property set to the		object.
	JSON value true if one or more of the identifiers provided in the
	initiation request identify a User at the AS, or the JSON value false		* *discovery* - if the AS Request included a discovery attribute,
	if not.		then the AS MAY return a "user" object with the "discovered"
			property set to the JSON value true if one or more of the
			identifiers provided in the AS Request identify a User at the AS,
			or the JSON value false if not. If the Client received a false
			return, it may
	[Editor: reference a security consideration for this functionality.]		[Editor: reference a security consideration for this functionality.]
	4.2. "interaction" Object		4.2. "interaction" Object
	If the AS wants the Client to start the interaction, the AS MUST		If the AS wants the Client to start the interaction, the AS MUST
	select one of the interaction mechanisms provided by the Client in		select one of the interaction mechanisms provided by the Client in
	the initiation request, and include the matching attribute in the		the AS Request, and include the matching attribute in the interaction
	interaction object:		object:
	* *type* - this MUST match the type provided by the Client in the		* *type* - this MUST match the type provided by the Client in the AS
	initiation request client.interaction object.		Request client.interaction object.
	* *uri* - the URI to interact with the User per the type. This may		* *uri* - the URI to interact with the User per the type. This may
	be a temporary short URL if the type is qrcode so that it is easy		be a temporary short URL if the type is qrcode so that it is easy
	to scan.		to scan.
	* *message* - a text string to display to the User if type is		* *message* - a text string to display to the User if type is
	qrcode.		qrcode.
	[Editor: do we specify a maximum length for the uri and message so		[Editor: do we specify a maximum length for the uri and message so
	that a device knows the maximum it needs to support? A smart device		that a device knows the maximum it needs to support? A smart device
	may have limited screen real estate.]		may have limited screen real estate.]
	4.3. "completion" Object		4.3. "authorization" Object
	The completion object has the following attributes:		The authorization object has the following attributes:
	* *handle* - the completion handle. This attribute is REQUIRED.		* *handle* - the authorization handle. This attribute is REQUIRED.
	* *uri* - the completion URI. This attribute is REQUIRED.		* *uri* - the authorization URI. This attribute is REQUIRED.
	* *wait* - the amount of time in integer seconds the Client MUST		* *wait* - the amount of time in integer seconds the Client MUST
	wait before making the completion request. This attribute is		wait before making the Authorization Request. This attribute is
	OPTIONAL.		OPTIONAL.
			4.4. "authentication" Object
			Returned if the Client requested authentication first. The
			authentication object has the following attributes:
			* *handle* - the authentication handle. This attribute is REQUIRED.
			* *uri* - the authentication URI. This attribute is REQUIRED.
	5. Interaction Types		5. Interaction Types
	If the AS wants the Client to initiate the interaction with the User,		If the AS wants the Client to initiate the interaction with the User,
	then the AS will return an interaction object Section 4.2 so that the		then the AS will return an interaction object Section 4.2 so that the
	Client can can hand off interactions with the User to the AS. The		Client can can hand off interactions with the User to the AS. The
	Client will initiate the interaction with the User in one of the		Client will initiate the interaction with the User in one of the
	following ways:		following ways:
	5.1. "popup" Type		5.1. "popup" Type
	The Client will create a new popup child browser window containing		The Client will create a new popup child browser window containing
	the value of the uri attribute of the interaction object. [Editor:		the value of the uri attribute of the interaction object. [Editor:
	more details on how to do this]		more details on how to do this]
	The AS will close the window when the interactions with the User are		The AS will close the window when the interactions with the User are
	complete. [Editor: confirm AS can do this still on all browsers, or		complete. [Editor: confirm AS can do this still on all browsers, or
	does Client need to close]		does Client need to close]
	The AS MAY respond to an outstanding completion request Section 8.10		The AS MAY respond to an outstanding Authorization Request
	before the popup window has been closed.		Section 8.13 before the popup window has been closed.
	5.2. "redirect" Type		5.2. "redirect" Type
	The Client will redirect the User to the value of the uri attribute		The Client will redirect the User to the value of the uri attribute
	of the interaction object. When the AS interactions with the User		of the interaction object. When the AS interactions with the User
	are complete, the AS will redirect the User to the redirect_uri the		are complete, the AS will redirect the User to the redirect_uri the
	Client provided in the initiation request.		Client provided in the AS Request.
	If the Client made a completion request when starting the		If the Client made a Authorization Request when starting the
	interaction, the AS MAY respond to the completion request		interaction, the AS MAY respond to the Authorization Request
	Section 8.10 before the User has been redirected back to the Client.		Section 8.13 before the User has been redirected back to the Client.
	5.3. "qrcode" Type		5.3. "qrcode" Type
	The Client will create a [QR_Code] of the uri attribute of the		The Client will create a [QR_Code] of the uri attribute of the
	interaction object and display the resulting graphic and the message		interaction object and display the resulting graphic and the message
	attribute of the interaction object as a text string.		attribute of the interaction object as a text string.
	6. Completion Response JSON		6. AS Response JSON
	Example non-normative completion response JSON document for Example 1		Example non-normative AS Response JSON document for Example 1 in
	in Section 3:		Section 3:
	{		{
	"iat":"15790460234",		"iat":"15790460234",
	"nonce":"f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce":"f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"authorizations": {		"authorizations": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_contacts",		"scope" : "read_contacts",
	"expires_in" : "3600",		"expires_in" : "3600",
	"method" : "bearer",		"method" : "bearer",
	"token" : "eyJJ2D6.example.access.token.mZf9p"		"token" : "eyJJ2D6.example.access.token.mZf9p"
	skipping to change at page 15, line 37 ¶		skipping to change at page 17, line 48 ¶
	"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"
	}		}
	}		}
	}		}
	}		}
	Example non-normative completion response JSON document for Example 2		Example non-normative AS Response JSON document for Example 2 in
	in Section 3:		Section 3:
	{		{
	"iat" :"15790460234",		"iat" :"15790460234",
	"nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"authorizations": {		"authorizations": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_calendar write_calendar",		"scope" : "read_calendar write_calendar",
	"expires_in" : "3600",		"expires_in" : "3600",
	"method" : "pop",		"method" : "pop",
	"access": {		"access": {
	skipping to change at page 16, line 32 ¶		skipping to change at page 18, line 32 ¶
	}		}
	}		}
	}		}
	Details of the JSON document:		Details of the JSON document:
	6.1. Top Level Attributes		6.1. Top Level Attributes
	*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 initiation request JSON		*nonce* - the nonce that was included in the AS Request JSON
	Section 3.		Section 3.
	6.2. "authorizations" Object		6.2. "authorizations" Object
	There is an authorizations object in the completion response if there		There is an authorizations object in the AS Response if there was an
	was an authorizations object in the initiation request.		authorizations object in the AS Request.
	* *type* - the type of claim request: "oauth_scope", "oauth_rich",		* *type* - the type of claim request: "oauth_scope", "oauth_rich",
	or "oauth_rich_list". See Section 3.6 for details.		or "oauth_rich_list". See Section 3.7 for details.
	* *list* - an array of objects if the type was "oauth_rich_list".		* *list* - an array of objects if the type was "oauth_rich_list".
	The objects have the following attributes just as if the type was		The objects have the following attributes just as if the type was
	"oauth_rich"		"oauth_rich"
	* *scope* - the scopes the Client was granted authorization for.		* *scope* - the scopes the Client was granted authorization for.
	This will be all, or a subset, of what was requested.		This will be all, or a subset, of what was requested.
	* *authorization_details* - the authorization details granted. Only		* *authorization_details* - the authorization details granted. Only
	returned for "oauth_rich" and "oauth_rich_list".		returned for "oauth_rich" and "oauth_rich_list".
	* *method* - the access method: "bearer" or "pop". See Section 6.4		* *method* - the access method: "bearer", "pop", or "jws". See
	for details.		Section 6.4 for details.
	* *token* - an access token for accessing the resource(s). Included		* *token* - an access token for accessing the resource(s). Included
	if the access method is "bearer".		if the access method is "bearer".
	* *expires_in* - an optional value specifying how many seconds until		* *expires_in* - an optional value specifying how many seconds until
	the access token or handle expire.		the access token or handle expire.
	* *refresh* - an optional object containing parameters required to		* *refresh* - an optional object containing parameters required to
	refresh an access token or handle. See refresh request		refresh an access token or handle. See refresh request
	Section 8.14.		Section 8.18.
	- *handle* - an refresh handle used to create the JSON refresh		- *handle* - an refresh handle used to create the JSON refresh
	token.		token.
	- *uri* - the refresh uri the Client will use to refresh.		- *uri* - the refresh uri the Client will use to refresh.
	* *access* - an object containing the parameters needed to access		* *access* - an object containing the parameters needed to access
	resources requiring proof-of-possession. Included if the access		resources requiring proof-of-possession. Included if the access
	method is "pop".		method is "pop".
	- *handle* - the access handle.		- *handle* - the access handle.
	- *jwk* - the jwk object to use.		- *jwk* - the jwk object to use.
	6.3. "claims" Object		6.3. "claims" Object
	There is a claims object in the completion response if there was a		There is a claims object in the AS Response if there was a claims
	claims object in the initiation request.		object in the AS Request.
	* *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
			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.4. Access Types		6.4. Access Methods
	There are two types of access to an RS:		The are three different methods for the Client to access an RS:
	* *bearer* - the AS provides a bearer access token that the Client		* *bearer* - the AS provides a bearer access token that the Client
	can use to access an RS per Section 8.12.		can use to access an RS per Section 8.15.
	* *pop* - the AS provides an access handle that the Client presents		* *pop* - the AS provides an access handle that the Client presents
	in a proof-of-possession RS access request per Section 8.13.		in a proof-of-possession RS access request per Section 8.16.
			* *pop_body* - the Client signs the JSON payload sent to the RS per
			Section 8.17.
			In the AS Response, the AS will return the method the Client MUST use
			when accessing the RS.
	7. Discovery		7. Discovery
	The Client obtains the following metadata about the AS prior to		The Client obtains the following metadata about the AS prior to
	initiating a request:		initiating a request:
	*Endpoint* - the endpoint of the AS.		*Endpoint* - the endpoint of the AS.
	*"as"* - the unique string identifier for the AS.		*"as"* - the unique string identifier for the AS.
	*Algorithms* - the asymetric cryptographic algorithms supported by		*Algorithms* - the asymetric cryptographic algorithms supported by
	the AS.		the AS.
	*Authorizations* - the authorizations the Client may request, if any.		*Authorizations* - the authorizations the Client may request, if any.
	*Identity Claims* - the identity claims the Client may request, if		*Identity Claims* - the identity claims the Client may request, if
	any, and what public keys the claims will be signed with.		any, and what public keys the claims will be signed with.
	The client may also obtain information about how the AS will sign		The client may also obtain information about how the AS will sign
	and/or encrypt the completion response, as well as any other metadata		and/or encrypt the AS Response, as well as any other metadata
	required for extensions to this protocol, as defined in those		required for extensions to this protocol, as defined in those
	extension specifications.		extension specifications.
	8. JOSE Client Authentication		8. JOSE Client Authentication
	The default mechanism for the Client to authenticate to the AS and		The default mechanism for the Client to authenticate to the AS and
	the RS is signing a JSON document with JWS per [RFC7515]. The		the RS is signing a JSON document with JWS per [RFC7515]. The
	resulting tokens always use compact serialization.		resulting tokens always use compact serialization.
	It is expected that extensions to this protocol that specify a		It is expected that extensions to this protocol that specify a
	different mechanism for the Client to authenticate, would over ride		different mechanism for the Client to authenticate, would over ride
	this section.		this section.
	The completion request JSON is signed with JWS and passed as the body		The Authorization Request JSON is signed with JWS and passed as the
	of the POST.		body of the POST.
	The completion, refresh, and access handles are signed with JWS		The authorization, refresh, and access handles are signed with JWS
	resulting in JOSE completion, refresh, and access tokens		resulting in authorization request, refresh, and access tokens
	respectively. These JOSE tokens are passed in the HTTP Authorization		respectively. These JOSE tokens are passed in the HTTP Authorization
	header with the "JOSE" parameter per Section 8.5.		header with the "JOSE" parameter per Section 8.6.
	The Client will use the same private key to create all tokens.		The Client will use the same private key to create all tokens.
	The Client and the AS MUST both use HTTP/2 ([RFC7540]) or later, and		The Client and the AS MUST both use HTTP/2 ([RFC7540]) or later, and
	TLS 1.3 ([RFC8446]) or later, when communicating with each other.		TLS 1.3 ([RFC8446]) or later, when communicating with each other.
	[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]		[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]
	8.1. JOSE Headers		8.1. JOSE Headers
	skipping to change at page 21, line 18 ¶		skipping to change at page 23, line 18 ¶
	"alg":"ES256",		"alg":"ES256",
	"typ":"JOSE",		"typ":"JOSE",
	"jwk":{		"jwk":{
	"kty":"EC",		"kty":"EC",
	"crv":"P-256",		"crv":"P-256",
	"x":"Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",		"x":"Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
	"y":"GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"		"y":"GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
	}		}
	}		}
	A non-normative example of a JOSE Access Token JOSE header for a		A non-normative example of a JOSE header for a JOSE access token for
	Client accessing an RS that requires proof-of-possession:		a Client accessing an RS that requires proof-of-possession:
	{		{
	"alg":"ES256",		"alg":"ES256",
	"typ":"JOSE",		"typ":"JOSE",
	"jwk":{		"jwk":{
	"x5u":"https://as.example/jwk/VBUEOIQA82"		"x5u":"https://as.example/jwk/VBUEOIQA82"
	}		}
	}		}
	The "jwk" object in a JOSE access token Section 8.4 MUST be the AS		The "jwk" object in a JOSE access token Section 8.5 MUST be the AS
	jwk object the AS provided with the access handle.		jwk object the AS provided with the access handle.
	This decouples how the AS communicates the Client's public key to the		This decouples how the AS communicates the Client's public key to the
	RS from how the AS asserts the Client's public key. The RS can have		RS from how the AS asserts the Client's public key. The RS can have
	a consistent mechanism assert the Client's public key across all		a consistent mechanism assert the Client's public key across all
	Clients.		Clients.
	One advantage of this is the AS can create a certificate of a Dynamic		One advantage of this is the AS can create a certificate of a Dynamic
	Client's public key, and pass it by value or reference to the Client		Client's public key, and pass it by value or reference to the Client
	to present to the RS.		to present to the RS.
	All JOSE headers MUST have: + the "alg" attribute. + the "typ"		All JOSE headers MUST have: + the "alg" attribute. + the "typ"
	attribute set to "jose". + either a "kid" or "jwk" attribute.		attribute set to "jose". + either a "kid" or "jwk" attribute.
	[Editor: should we use indicate the type of token (completion,		[Editor: should we use indicate the type of token (authorization,
	refresh, access) using "typ" or "cty"?]		refresh, access) using "typ" or "cty"?]
	8.2. JOSE Completion Token		8.2. Authentication Request Token
	A non-normative example of a payload follows:		A non-normative example of a payload follows:
	{		{
	"as" :"https://as.example",		"as" :"https://as.example",
	"type" :"completion",		"type" :"authentication",
	"iat" :"1579046092",		"iat" :"1579046092",
	"jti" :"f6d72254-4f23-417f-b55e-14ad323b1dc1",		"jti" :"f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"handle":"eyJhb958.example.completion.handle.9yf3szM"		"handle":"eyJhb958.example.authentication.handle.9yf3szM"
	}		}
	The payload of the completion token contains:		The payload of the authentication token contains:
	*as* - the unique string identifier for the AS.		*as* - the unique string identifier for the AS.
	*type* - the string "completion", indicating the type of token.		*type* - the string "authentication", indicating the type of token.
	*iat* - the time the completion token was created as a NumericDate.		*iat* - the time the authentication token was created as a
			NumericDate.
	*jti* - a unique identifier for the completion token per [RFC7519]		*jti* - a unique identifier for the authentication token per
			[RFC7519] section 4.1.7.
			*handle* the authentication handle the AS provided the Client in the
			Interaction Response Section 4.
			8.3. Authorization Request Token
			A non-normative example of a payload follows:
			{
			"as" :"https://as.example",
			"type" :"authorization",
			"iat" :"1579046092",
			"jti" :"f6d72254-4f23-417f-b55e-14ad323b1dc1",
			"handle":"eyJhb958.example.authorization.handle.9yf3szM"
			}
			The payload of the authorization token contains:
			*as* - the unique string identifier for the AS.
			*type* - the string "authorization", indicating the type of token.
			*iat* - the time the authorization token was created as a
			NumericDate.
			*jti* - a unique identifier for the authorization token per [RFC7519]
	section 4.1.7.		section 4.1.7.
	*handle* the completion handle the AS provided the Client in the		*handle* the authorization handle the AS provided the Client in the
	initiation response Section 4.		Interaction Response Section 4.
	8.3. JOSE Refresh Token		8.4. Refresh Token
	A non-normative example of a payload follows:		A non-normative example of a payload follows:
	{		{
	"as" :"https://as.example",		"as" :"https://as.example",
	"type" :"refresh",		"type" :"refresh",
	"iat" :"1579049876",		"iat" :"1579049876",
	"jti" :"4342046d-83c4-4725-8c72-e9a49245f791",		"jti" :"4342046d-83c4-4725-8c72-e9a49245f791",
	"handle":"eyJhb958.example.refresh.handle.9yf3szM"		"handle":"eyJhb958.example.refresh.handle.9yf3szM"
	}		}
	The payload of the completion token contains:		The payload of the authorization token contains:
	*as* - the unique string identifier for the AS.		*as* - the unique string identifier for the AS.
	*type* - the string "refresh", indicating the type of token.		*type* - the string "refresh", indicating the type of token.
	*iat* - the time the JOSE refresh token was created as a NumericDate.		*iat* - the time the refresh request token was created as a
			NumericDate.
	*jti* - a unique identifier for the JOSE refresh token.		*jti* - a unique identifier for the refresh request token.
	*handle* the refresh handle the AS provided the Client in the		*handle* the refresh handle the AS provided the Client in the AS
	completion response Section 6 or access refresh response		Response Section 6 or access refresh response Section 8.18.
	Section 8.14.
	8.4. JOSE Access Token		8.5. JOSE Access Token
	The "jwk" object in a JOSE access token header MUST be set to the		The "jwk" object in a JOSE access token header MUST be set to the
	"jwk" value the AS provided for the access handle.		"jwk" value the AS provided for the access handle.
	A non-normative example of a payload follows:		A non-normative example of a payload follows:
	{		{
	"type" :"access",		"type" :"access",
	"iat" :"1579046092",		"iat" :"1579046092",
	"jti" :"5ef47057-08f9-4763-be8d-162824d43dfb",		"jti" :"5ef47057-08f9-4763-be8d-162824d43dfb",
	skipping to change at page 23, line 27 ¶		skipping to change at page 26, line 7 ¶
	}		}
	The payload of the JOSE access token contains:		The payload of the JOSE access token contains:
	*type* - the string "access", indicating the type of token.		*type* - the string "access", indicating the type of token.
	*iat* - the time the JOSE access token was created as a NumericDate.		*iat* - the time the JOSE access token was created as a NumericDate.
	*jti* - a unique identifier for the JOSE access token.		*jti* - a unique identifier for the JOSE access token.
	*handle* the access handle the AS provided the Client in the		*handle* the access handle the AS provided the Client in the AS
	completion response Section 6 or access refresh response		Response Section 6 or access refresh response Section 8.18.
	Section 8.14.
	8.5. HTTP Authorization JOSE Header		[Editor: should we include the called URI in the token?]
			8.6. HTTP Authorization JOSE Header
	The Client authenticates requests by setting the HTTP Authorization		The Client authenticates requests by setting the HTTP Authorization
	header to include the "JOSE" parameter, followed by one or more space		header to include the "JOSE" parameter, followed by one or more space
	characters, followed by the appropriate JOSE token.		characters, followed by the appropriate JOSE token.
	A non-normative example:		A non-normative example:
	Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW		Authorization: JOSE eyJhb.example.authorization.token.haDwskpFDBW
	The JOSE completion token, JOSE refresh token, and the JOSE access		The authorization request token, refresh request token, and the JOSE
	token are all passed in this manner.		access token are all passed in this manner.
	8.6. JOSE Token Verification		8.7. JOSE Token Verification
	TBD		TBD
	8.7. Initiation Request		8.8. AS Request
	The Client creates a JSON document per Section 3, signs it using JWS		The Client creates a JSON document per Section 3, signs it using JWS
	[RFC7515], and sends the JWS token to the AS end point using HTTP		[RFC7515], and sends the JWS token to the AS end point using HTTP
	POST, with a content-type of application/jose.		POST, with a content-type of application/jose.
	* *Payload Encryption*		* *Payload Encryption*
	The AS may require the initiation request to be encrypted. If so,		The AS may require the AS Request to be encrypted. If so, the JWS
	the JWS token is encrypted per JWE [RFC7516] using the public key and		token is encrypted per JWE [RFC7516] using the public key and
	algorithm specified by the AS.		algorithm specified by the AS.
	8.8. Initiation Response		8.9. Interaction Response
	If no interaction is required the AS will return a completion		If the Client set the authenticate_first flag, the response includes
	response per Section 8.11, otherwise the AS will return an initiation		an authentication object, otherwise it includes an authorization
	response per Section 4.		object. If the AS wants the Client to initiate the User interaction,
			it sends an interaction object.
			If no interaction is required the AS will return an AS Response per
			Section 8.14, otherwise the AS will return an Interaction Response
			per Section 4.
	If the AS wants the Client to start the interaction, an interaction		If the AS wants the Client to start the interaction, an interaction
	object will be returned in the response.		object will be returned in the response.
	* *Error Responses*		* *Error Responses*
	The AS MAY respond with one of the following errors defined in		The AS MAY respond with one of the following errors defined in
	Section 9:		Section 9:
	TBD		TBD
	8.9. Deletion Request		8.10. Deletion Request
	The Client MAY delete an outstanding request using the completion		The Client MAY delete an outstanding request using the authorization
	token by making an HTTP DELETE call to the completion uri, setting		token by making an HTTP DELETE call to the authorization uri, setting
	the HTTP Authorization header per Section 8.5 with the JOSE		the HTTP Authorization header per Section 8.6 with the authorization
	completion token.		request token.
	A non-normative deletion request example:		A non-normative deletion request example:
	DELETE /completion/ey7snHGs HTTP/2		DELETE /authorization/ey7snHGs HTTP/2
	Host: as.example		Host: as.example
	Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW		Authorization: JOSE eyJhb.example.authorization.token.haDwskpFDBW
	* *Error Responses*		* *Error Responses*
	The AS MAY respond with one of the following errors defined in		The AS MAY respond with one of the following errors defined in
	Section 9:		Section 9:
	TBD		TBD
	8.10. Completion Request		8.11. Authentication Request
	The Client makes an HTTP GET call to the completion uri, setting the		Section 8.2
	HTTP Authorization header per Section 8.5 with the JOSE completion
	token.
	A non-normative completion request example:		8.12. Authentication Response
	GET /completion/ey7snHGs HTTP/2		8.13. Authorization Request
			The Client makes an HTTP GET call to the authorization uri, setting
			the HTTP Authorization header per Section 8.6 with the authorization
			request token.
			A non-normative Authorization Request example:
			GET /authorization/ey7snHGs HTTP/2
	Host: as.example		Host: as.example
	Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW		Authorization: JOSE eyJhb.example.authorization.token.haDwskpFDBW
	8.11. Completion Response		8.14. AS Response
	The AS verifies the JOSE completion token, and then provides a		The AS verifies the authorization request token, and then provides a
	response according to what the User and/or RO have authorized if		response according to what the User and/or RO have authorized if
	required. If no signature or encryption was required, the AS will		required. If no signature or encryption was required, the AS will
	respond with a JSON document with content-type set to application/		respond with a JSON document with content-type set to application/
	json.		json.
	* *Response Signing*		* *Response Signing*
	The AS MAY sign the response with a JWS per [RFC7515] and the private		The AS MAY sign the response with a JWS per [RFC7515] and the private
	key matching the public key the AS defined as its completion response		key matching the public key the AS defined as its AS Response signing
	signing key. The AS will respond with the content-type set to		key. The AS will respond with the content-type set to application/
	application/jose.		jose.
	* *Response Encryption*		* *Response Encryption*
	The AS MAY encrypt the response using the public key provided by the		The AS MAY encrypt the response using the public key provided by the
	Client, using JWE per [RFC7516]. The AS will respond with the		Client, using JWE per [RFC7516]. The AS will respond with the
	content-type set to application/jose.		content-type set to application/jose.
	* *Error Responses*		* *Error Responses*
	The AS MAY respond with one of the following errors defined in		The AS MAY respond with one of the following errors defined in
	Section 9:		Section 9:
	TBD		TBD
	8.12. Bearer Token RS Access		8.15. Bearer Token RS Access
	If the access method in the completion response authorizations object		If the access method in the AS Response authorizations object
	Section 6.2 was "bearer", then the Client accesses the RS per		Section 6.2 was "bearer", then the Client accesses the RS per
	Section 2.1 of [RFC6750]		Section 2.1 of [RFC6750]
	A non-normative example of the HTTP request headers follows:		A non-normative example of the HTTP request headers follows:
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA		Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA
	* *Error Responses*		* *Error Responses*
	skipping to change at page 26, line 4 ¶		skipping to change at page 28, line 46 ¶
	Section 6.2 was "bearer", then the Client accesses the RS per		Section 6.2 was "bearer", then the Client accesses the RS per
	Section 2.1 of [RFC6750]		Section 2.1 of [RFC6750]
	A non-normative example of the HTTP request headers follows:		A non-normative example of the HTTP request headers follows:
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA		Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA
	* *Error Responses*		* *Error Responses*
	TBD		TBD
	8.13. Proof-of-possession RS Access		8.16. Proof-of-possession RS Access
	If the access method in the completion response authorizations object		If the access method in the AS Response authorizations object
	Section 6.2 was "pop", then the Client creates a JOSE access token		Section 6.2 was "pop", then the Client creates a JOSE access token
	per Section 8.4 for each call to the RS, setting the HTTP		per Section 8.5 for each call to the RS, setting the HTTP
	Authorization header per Section 8.5 with the JOSE access token.		Authorization header per Section 8.6 with the JOSE access token.
	A non-normative example of the HTTP request headers follows:		A non-normative example of the HTTP request headers follows:
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	Authorization: JOSE eyJhbG.example.JOSE.access.token.kwwQb958		Authorization: JOSE eyJhbG.example.JOSE.access.token.kwwQb958
	* *Error Responses*		* *Error Responses*
	TBD		TBD
	8.14. Access Refresh		8.17. JOSE Body RS Access
			If the access method in the AS Response authorizations object
			Section 6.2 was "pop_body", then the Client creates a JOSE access
			token per Section 8.5 for each call to the RS, setting the HTTP
			Authorization header per Section 8.6 with the JOSE access token.
			The Client creates a JSON document per the RS requirements. The
			document MUST include the access handle. The CLient then signs the
			document using JWS [RFC7515], and sends the resulting compact
			notation JWS token to the RS end point using HTTP POST, with a
			content-type of application/jose. Note this is similar to the AS
			Request Section 8.8.
			[Editor: any isues here? Anything missing that MUST be in the
			payload? Would an HTTP Authorization header make sense?]
			8.18. Access Refresh
	If the Client received a refresh handle and uri from the AS in the		If the Client received a refresh handle and uri from the AS in the
	initiation response, and it wants a fresh access token or handle, it		Interaction Response, and it wants a fresh access token or handle, it
	creates a JOSE refresh token per Section 8.3. setting the HTTP		creates a refresh request token per Section 8.4. setting the HTTP
	Authorization header per Section 8.5 with the JOSE refresh token.		Authorization header per Section 8.6 with the refresh request token.
	The AS will then respond with a refresh response.		The AS will then respond with a refresh response.
	* *Refresh Response*		* *Refresh Response*
	A non-normative example refresh response with an access handle:		A non-normative example refresh response with an access handle:
	{		{
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_calendar write_calendar",		"scope" : "read_calendar write_calendar",
	"expires_in" : "3600",		"expires_in" : "3600",
	skipping to change at page 27, line 4 ¶		skipping to change at page 30, line 21 ¶
	"handle" : "ey.example.access.handle.9yf3iWszM",		"handle" : "ey.example.access.handle.9yf3iWszM",
	"jwk": {		"jwk": {
	"x5u" : "https://as.example/jwk/VBUEOIQA82"		"x5u" : "https://as.example/jwk/VBUEOIQA82"
	}		}
	},		},
	"refresh": {		"refresh": {
	"handle" : "ey.example.refresh.handle.4SkjIi",		"handle" : "ey.example.refresh.handle.4SkjIi",
	"uri" : "https://as.example/refresh/eyJl4FzM"		"uri" : "https://as.example/refresh/eyJl4FzM"
	}		}
	}		}
	The refresh response is the same as the authorizations object		The refresh response is the same as the authorizations object
	Section 6.2 in the completion response.		Section 6.2 in the AS Response.
	If a new refresh handle and/or refresh uri is returned, the Client		If a new refresh handle and/or refresh uri is returned, the Client
	MUST use the new refresh handle and/or refresh uri		MUST use the new refresh handle and/or refresh uri
	[Editor: are there other results relevant for [RAR]?]		[Editor: are there other results relevant for [RAR]?]
	* *Error Responses*		* *Error Responses*
	The AS MAY respond with one of the following errors defined in		The AS MAY respond with one of the following errors defined in
	Section 9:		Section 9:
	TBD		TBD
	9. Error Messages		9. Error Messages
	\[Editor: return "wait" time in completion response when AS wants Client to wait before retying a completion request.		[Editor: return "wait" time in AS Response when AS wants Client to
	The Client MUST generate a fresh completion token when retrying the completion request.		wait before retying a Authorization Request. The Client MUST
	]		generate a fresh authorization token when retrying the Authorization
			Request. ]
	TBD		TBD
	10. AS Initiated Sequence		10. AS Initiated Sequence
	[Editor: AS initiated flows have been challenging to implement as		[Editor: AS initiated flows have been challenging to implement as
	OAuth 2.0 did not directly support them, so deployments bounced back		OAuth 2.0 did not directly support them, so deployments bounced back
	and forth between the Client and AS to create a Client initiated		and forth between the Client and AS to create a Client initiated
	flow. Here is a proposal to support AS initiated: authentication;		flow. Here is a proposal to support AS initiated: authentication;
	just-in-time (JIT) provisioning; and authorization]		just-in-time (JIT) provisioning; and authorization]
	skipping to change at page 27, line 34 ¶		skipping to change at page 31, line 4 ¶
	TBD		TBD
	10. AS Initiated Sequence		10. AS Initiated Sequence
	[Editor: AS initiated flows have been challenging to implement as		[Editor: AS initiated flows have been challenging to implement as
	OAuth 2.0 did not directly support them, so deployments bounced back		OAuth 2.0 did not directly support them, so deployments bounced back
	and forth between the Client and AS to create a Client initiated		and forth between the Client and AS to create a Client initiated
	flow. Here is a proposal to support AS initiated: authentication;		flow. Here is a proposal to support AS initiated: authentication;
	just-in-time (JIT) provisioning; and authorization]		just-in-time (JIT) provisioning; and authorization]
	In this sequence the User starts at the AS, and then based on User		In this sequence the User starts at the AS, and then based on User
	input, the AS redirects the User to a Client, passing an initiation		input, the AS redirects the User to a Client, passing an initiation
	token Section 10.1, and then the Client retrieves authorizations and/		token Section 10.1, and then the Client retrieves authorizations and/
	or identity claims about the User. The Client MUST be a Registered		or identity claims about the User. The Client MUST be a Registered
	Client. The sequence follows:		Client. The sequence follows:
	1. The User is interacting at the AS and wants to use the Client,		1. The User is interacting at the AS and wants to use the Client,
	and provide the Client identity claims and/or authorizations from		and provide the Client identity claims and/or authorizations from
	the AS that the Client has pre-configured.		the AS that the Client has pre-configured.
	2. The AS creates a completion handle and uri representing the		2. The AS creates a authorization handle and uri representing the
	identity claims and authorizations to be provided to the Client.		identity claims and authorizations to be provided to the Client.
	The AS creates an initiation token containing the AS identifier,		The AS creates an initiation token containing the AS identifier,
	the completion handle, and the completion uri.		the authorization handle, and the authorization uri.
	3. The AS redirects the User to a URI the Client has configured to		3. The AS redirects the User to a URI the Client has configured to
	accept initiation tokens, passing the initiation token as a query		accept initiation tokens, passing the initiation token as a query
	parameters with the name "token".		parameters with the name "token".
	4. The Client verifies the initiation token.		4. The Client verifies the initiation token.
	5. The Client makes a completion request per Section 8.10.		5. The Client makes an Authorization Request per Section 8.13.
	6. The AS responds with a completion response JSON document		6. The AS responds with an AS Response JSON document Section 6 per
	Section 6 per Section 8.11.		Section 8.14.
	The Client now has the User identity claims and/or authorizations.		The Client now has the User identity claims and/or authorizations.
	If Client policy permits, the Client can perform JIT provisioning if		If Client policy permits, the Client can perform JIT provisioning if
	the User is new to the Client.		the User is new to the Client.
	*AS Initiated Sequence Diagram*		*AS Initiated Sequence Diagram*
	+--------+ +-------------+ +---------------+		+--------+ +-------------+ +---------------+
	| | | | | |		| | | | | |
	| | | User |-------(1)-->| |		| | | User |-------(1)-->| |
	| | | | | |		| | | | | |
	| | +-------------+ | (2) |		| | +-------------+ | (2) |
	| | /\ | |		| | /\ | |
	| Client |<--- initiation ---/ \-------------(3)---| Authorization |		| Client |<--- initiation ---/ \-------------(3)---| Authorization |
	| | token | Server |		| | token | Server |
	| (4) | | |		| (4) | | |
	| | | |		| | | |
	| |--(5)------- Completion Request --------->| |		| |--(5)------- Authorization Request ------>| |
	| | | |		| | | |
	| |<-(6)------- Completion Response ---------| |		| |<-(6)------- AS Response -----------------| |
	| | | |		| | | |
	+--------+ +---------------+		+--------+ +---------------+
	10.1. Initiation Token		10.1. Initiation Token
	A non-normative example of an initiation token payload follows:		A non-normative example of an initiation token payload follows:
	{		{
	"as": "https://as.example",		"as": "https://as.example",
	"completion": {		"authorization": {
	"handle" : "eyJhb958.example.completion.handle.9yf3szM",		"handle" : "eyJhb958.example.authorization.handle.9yf3szM",
	"uri" : "https://as.example/completion/ey7snHGs"		"uri" : "https://as.example/authorization/ey7snHGs"
	}		}
	}		}
	* *as* - the "as" identifier for the AS. This attribute is		* *as* - the "as" identifier for the AS. This attribute is
	REQUIRED.		REQUIRED.
	* *completion* - the completion object has the following attributes:		* *authorization* - the authorization object has the following
			attributes:
	- *handle* - the completion handle. This attribute is REQUIRED.		- *handle* - the authorization handle. This attribute is
			REQUIRED.
	- *uri* - the completion URI. This attribute is REQUIRED.		- *uri* - the authorization URI. This attribute is REQUIRED.
	The initiation token is signed with JWS and uses the compact		The initiation token is signed with JWS and uses the compact
	serialization.		serialization.
	11. Extensibility		11. Extensibility
	This standard can be extended in a number of areas:		This standard can be extended in a number of areas:
	* *Client Authentication Mechanisms*		* *Client Authentication Mechanisms*
	An extension could define other mechanisms for the Client to		An extension could define other mechanisms for the Client to
	authenticate and replace JOSE in Section 8 with Mutual TLS or HTTP		authenticate and replace JOSE in Section 8 with Mutual TLS or HTTP
	Signing. Constrained environments could use CBOR [RFC7049] instead		Signing. Constrained environments could use CBOR [RFC7049] instead
	of JSON, and COSE [RFC8152] instead of JOSE, and CoAP [RFC8323]		of JSON, and COSE [RFC8152] instead of JOSE, and CoAP [RFC8323]
	instead of HTTP/2.		instead of HTTP/2.
	* *Initiation Request*		* *AS Request*
	An additional top level object could be added to the initiation		An additional top level object could be added to the AS Request
	request payload if the AS can manage delegations other than		payload if the AS can manage delegations other than authorizations or
	authorizations or claims, or some other functionality.		claims, or some other functionality.
	* *"client" Object*		* *"client" Object*
	Additional information about the Client that the AS would require		Additional information about the Client that the AS would require
	related to an extension.		related to an extension.
	* *"user" Object*		* *"user" Object*
	Additional information about the Client that the AS would require		Additional information about the Client that the AS would require
	related to an extension.		related to an extension.
	skipping to change at page 30, line 4 ¶		skipping to change at page 33, line 21 ¶
	Additional types of authorizations in addition to OAuth 2.0 scopes		Additional types of authorizations in addition to OAuth 2.0 scopes
	and RAR.		and RAR.
	* *"claims" Object*		* *"claims" Object*
	Additional types of identity claims in addition to OpenID Connect		Additional types of identity claims in addition to OpenID Connect
	claims and Verified Credentials.		claims and Verified Credentials.
	* *Interaction*		* *Interaction*
	Additional mechanisms for the Client to start an interaction with the		Additional mechanisms for the Client to start an interaction with the
	User.		User.
	* *Access Methods*		* *Access Methods*
	Additional mechanisms for the Client to present authorization to a		Additional mechanisms for the Client to present authorization to a
	resource.		resource.
			* *Continuous Authentication*
			An extension could define a new handle for the Client to use to
			regularly provide continuous authentication signals and receive
			responses.
	[Editor: do we specify access token / handle introspection in this		[Editor: do we specify access token / handle introspection in this
	document, or leave that to an extension?]		document, or leave that to an extension?]
	[Editor: do we specify access token / handle revocation in this		[Editor: do we specify access token / handle revocation in this
	document, or leave that to an extension?]		document, or leave that to an extension?]
	12. Rational		12. Rational
	1. *Why is there only one mechanism for the Client to authenticate		1. *Why is there only one mechanism for the Client to authenticate
	with the AS? Why not support other mechanisms?*		with the AS? Why not support other mechanisms?*
	skipping to change at page 31, line 29 ¶		skipping to change at page 35, line 4 ¶
	many of the security risks in OAuth 2.0. It also presents a		many of the security risks in OAuth 2.0. It also presents a
	challenge for smart devices. In this protocol, the redirection		challenge for smart devices. In this protocol, the redirection
	from the Client to the AS is to enable the AS to interact with		from the Client to the AS is to enable the AS to interact with
	the User, and the redirection back to the Client is to hand back		the User, and the redirection back to the Client is to hand back
	interaction control to the Client if the redirection was a full		interaction control to the Client if the redirection was a full
	browser redirect. Unlike OAuth 2.0, the identity of the Client		browser redirect. Unlike OAuth 2.0, the identity of the Client
	is independent of the URI the AS redirects to.		is independent of the URI the AS redirects to.
	6. *Why is there not a UserInfo endpoint as there is with OpenID		6. *Why is there not a UserInfo endpoint as there is with OpenID
	Connect?*		Connect?*
	In OpenID Connect, obtaining claims over the redirect or the		In OpenID Connect, obtaining claims over the redirect or the
	Token Endpoint are problematic. The redirect is limited in		Token Endpoint are problematic. The redirect is limited in
	size, and is not secure. The Token Endpoint is intended to		size, and is not secure. The Token Endpoint is intended to
	return tokens, and is limited by the "application/x-www-form-		return tokens, and is limited by the "application/x-www-form-
	urlencoded" format. A UserInfo endpoint returns "application/		urlencoded" format. A UserInfo endpoint returns "application/
	json", and can return rich claims, just as the completion uri in		json", and can return rich claims, just as the authorization uri
	this protocol.		in this protocol.
	[Editor: is there some other reason to have the UserInfo		[Editor: is there some other reason to have the UserInfo
	endpoint? What are industry best practices now? ]		endpoint? What are industry best practices now? ]
	7. *Why is there still a Client ID? Could we not use a fingerprint		7. *Why is there still a Client ID? Could we not use a fingerprint
	of the public key to identify the Client?*		of the public key to identify the Client?*
	Some AS deployments do not allow calls from Registered Clients,		Some AS deployments do not allow calls from Registered Clients,
	and provide different functionality to different Clients. A		and provide different functionality to different Clients. A
	permanent identifier for the Client is needed for the Client		permanent identifier for the Client is needed for the Client
	skipping to change at page 32, line 4 ¶		skipping to change at page 35, line 26 ¶
	of the public key to identify the Client?*		of the public key to identify the Client?*
	Some AS deployments do not allow calls from Registered Clients,		Some AS deployments do not allow calls from Registered Clients,
	and provide different functionality to different Clients. A		and provide different functionality to different Clients. A
	permanent identifier for the Client is needed for the Client		permanent identifier for the Client is needed for the Client
	developer and the AS admin to ensure they are referring to the		developer and the AS admin to ensure they are referring to the
	same Client. The Client ID was used in OAuth 2.0, and it served		same Client. The Client ID was used in OAuth 2.0, and it served
	the same purpose.		the same purpose.
	8. *Why have both claims and authorizations?*		8. *Why have both claims and authorizations?*
	There are use cases for each that are independent:		There are use cases for each that are independent:
	authenticating a user vs granting access to a resource. A		authenticating a user vs granting access to a resource. A
	request for an authorization returns an access token or handle,		request for an authorization returns an access token or handle,
	while a request for a claim returns the claim.		while a request for a claim returns the claim.
	9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and		9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and
	AS communication in ?*Section 8		AS communication in ?*Section 8
	Knowing the AS supports HTTP/2 enables a Client to set up a		Knowing the AS supports HTTP/2 enables a Client to set up a
	connection faster. HTTP/2 will be more efficient when Clients		connection faster. HTTP/2 will be more efficient when Clients
	have large numbers of access tokens and are frequently		have large numbers of access tokens and are frequently
	refreshing them at the AS as there will be less network traffic.		refreshing them at the AS as there will be less network traffic.
	Mandating TLS 1.3 similarly improves the performance and		Mandating TLS 1.3 similarly improves the performance and
	security of Clients and AS when setting up a TLS connection.		security of Clients and AS when setting up a TLS connection.
	10. *Why do some of the JSON objects only have one child, such as		10. *Why do some of the JSON objects only have one child, such as
	the identifiers object in the user object in the initiation		the identifiers object in the user object in the AS Request?*
	request?*
	It is difficult to forecast future use cases. Having more		It is difficult to forecast future use cases. Having more
	resolution may mean the difference between a simple extension,		resolution may mean the difference between a simple extension,
	and a convoluted extension.		and a convoluted extension.
	11. *Why is the "iss" included in the "oidc" identifier object?		11. *Why is the "iss" included in the "oidc" identifier object?
	Would the "sub" not be enough for the AS to identify the User?*		Would the "sub" not be enough for the AS to identify the User?*
	The AS may use another AS to authenticate Users. The "iss" and		The AS may use another AS to authenticate Users. The "iss" and
	"sub" combination is required to uniquely identify the User for		"sub" combination is required to uniquely identify the User for
	any AS.		any AS.
			12. *Why complicate the sequence with authentication first?*
			A common pattern is to use an AS to authenticate the User at the
			Client. 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 identity claims and/or authorizations they have
			already provided is a poor User experience, as is sending the
			User back to the AS. The Client requesting identity first
			enables the Client to get a response from the AS while the AS is
			still interacting with the User, so that the Client can request
			any identity claims/or authorizations required or desired.
			13. *Why is there a JOSE Body access method for the
			Client?*Section 8.17
			There are numerous use cases where the RS wants non-repudiation
			and providence of API calls. For example, the UAS Service
			Supplier Framework for Authentication and Authorization [UTM].
	13. Acknowledgments		13. Acknowledgments
	This draft derives many of its concepts from Justin Richer's		This draft derives many of its concepts from Justin Richer's
	Transactional Authorization draft [TxAuth].		Transactional Authorization draft [TxAuth].
	Additional thanks to Justin Richer for his strong critique of earlier		Additional thanks to Justin Richer for his strong critique of earlier
	drafts.		drafts.
	14. IANA Considerations		14. IANA Considerations
	skipping to change at page 34, line 13 ¶		skipping to change at page 38, line 5 ¶
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<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
			Assurance 1.0", October 2019, <https://openid.net/specs/
			openid-connect-4-identity-assurance-1_0.html>.
	16.2. Informative References		16.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",		[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,		BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
	<https://www.rfc-editor.org/info/rfc8252>.		<https://www.rfc-editor.org/info/rfc8252>.
	skipping to change at page 35, line 11 ¶		skipping to change at page 39, line 9 ¶
	[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 Authorization", December 2019,		[TxAuth] Richer, J., "Transactional Authorization", 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, "UAS Service
			Supplier Framework for Authentication and Authorization",
			September 2019, <https://utm.arc.nasa.gov/docs/2019-
			UTM_Framework-NASA-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
			* text clean up
			* added OIDC4IA claims
			* added "jws" method for accessing a resource.
			* renamed Initiation Request -> AS Request
			* renamed Initiation Response -> Interaction Response
			* renamed Completion Request -> Authorization Request
			* renamed Completion Response -> AS Request
			* renamed completion handle -> authorization handle
			* added Authentication Request, Authentication Response,
			authentication handle
	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 differences between this protocol and OAuth 2.0 and OpenID		The major differences between this protocol and OAuth 2.0 and OpenID
	Connect are:		Connect are:
	* The Client uses a private key to authenticate in this protocol		* The Client uses a private key to authenticate in this protocol
	instead of the client secret in OAuth 2.0 and OpenID Connect.		instead of the client secret in OAuth 2.0 and OpenID Connect.
End of changes. 141 change blocks.
	297 lines changed or deleted		545 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/