< draft-hardt-xauth-protocol-05.txt		draft-hardt-xauth-protocol-06.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 7 March 2020		Intended status: Standards Track 22 March 2020
	Expires: 8 September 2020		Expires: 23 September 2020
	The XAuth Protocol		The XAuth Protocol
	draft-hardt-xauth-protocol-05		draft-hardt-xauth-protocol-06
	Abstract		Abstract
	Client software often desires resources or identity claims that are		Client software often desires resources or identity claims that are
	independent of the client. This protocol allows a user and/or		independent of the client. This protocol allows a user and/or
	resource owner to delegate resource authorization and/or release of		resource owner to delegate resource authorization and/or release of
	identity claims to a server. Client software can then request access		identity claims to a server. Client software can then request access
	to resources and/or identity claims by calling the server. The		to resources and/or identity claims by calling the server. The
	server acquires consent and authorization from the user and/or		server acquires consent and authorization from the user and/or
	resource owner if required, and then returns to the client software		resource owner if required, and then returns to the client software
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 8 September 2020.		This Internet-Draft will expire on 23 September 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 45		10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 45
	10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 45		10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 45
	10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 46		10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 46
	10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 47		10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 47
	10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 48		10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 48
	10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 48		10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 48
	10.5. Response Encryption . . . . . . . . . . . . . . . . . . 48		10.5. Response Encryption . . . . . . . . . . . . . . . . . . 48
	11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 48		11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 48
	12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 49		12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 54		15. Security Considerations . . . . . . . . . . . . . . . . . . . 53
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	16.1. Normative References . . . . . . . . . . . . . . . . . . 54		16.1. Normative References . . . . . . . . . . . . . . . . . . 53
	16.2. Informative References . . . . . . . . . . . . . . . . . 55		16.2. Informative References . . . . . . . . . . . . . . . . . 55
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 56		Appendix A. Document History . . . . . . . . . . . . . . . . . . 56
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 56		A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 56
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 56		A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 56
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 57		A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 57
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 57		A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 57
	A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 57		A.5. draft-hardt-xauth-protocol-04 . . . . . . . . . . . . . . 57
	A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 57		A.6. draft-hardt-xauth-protocol-05 . . . . . . . . . . . . . . 57
			A.7. draft-hardt-xauth-protocol-06 . . . . . . . . . . . . . . 57
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 58		Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 58
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59
	1. Introduction		1. Introduction
	This protocol supports the widely deployed use cases supported by		This protocol supports the widely deployed use cases supported by
	OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an		OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an
	extension of OAuth 2.0, as well as other extensions, and other use		extension of OAuth 2.0, as well as other extensions, and other use
	cases that are not supported, such as acquiring multiple access		cases that are not supported, such as acquiring multiple access
	tokens at the same time, and updating the request during user		tokens at the same time, and updating the request during user
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 20 ¶
	* claims		* claims
	The GS MUST respond with one of Grant Response Section 6.1,		The GS MUST respond with one of Grant Response Section 6.1,
	Interaction Response Section 6.2, Wait Response Section 6.3, or one		Interaction Response Section 6.2, Wait Response Section 6.3, or one
	of the following errors:		of the following errors:
	* TBD		* TBD
	from Error Responses Section 9.		from Error Responses Section 9.
	Following is a non-normative example where the Client wants to		Following is a non-normative example where the Client wants is
	interact with the User with a popup and is requesting identity claims		requesting identity claims about the User and read access to the
	about the User and read access to the User's contacts:		User's contacts:
	Example 1		Example 1
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"client": {		"client": {
	"display": {		"display": {
	"name" : "SPA Display Name",		"name" : "SPA Display Name",
	"uri" : "https://spa.example/about"		"uri" : "https://spa.example/about"
	}		}
	},		},
	"interaction": {		"interaction": {
	"type" : "popup"		"type" : "redirect",
			"completion_uri" : "https://web.example/return"
	},		},
	"authorization": {		"authorization": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	"scope" : "read_contacts"		"scope" : "read_contacts"
	},		},
	"claims": {		"claims": {
	"oidc": {		"oidc": {
	"id_token" : {		"id_token" : {
	"email" : { "essential" : true },		"email" : { "essential" : true },
	"email_verified" : { "essential" : true }		"email_verified" : { "essential" : true }
	skipping to change at page 24, line 15 ¶		skipping to change at page 24, line 15 ¶
	Example 2		Example 2
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"uri" : "https://as.example/endpoint",		"uri" : "https://as.example/endpoint",
	"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",		"nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
	"client": {		"client": {
	"id" : "di3872h34dkJW"		"id" : "di3872h34dkJW"
	},		},
	"interaction": {		"interaction": {
	"keep" : true,		"keep" : true,
	"type" : "redirect",		"type" : "redirect",
	"redirect_uri" : "https://web.example/return"		"completion_uri" : "https://web.example/return"
	},		},
	"user": {		"user": {
	"identifiers": {		"identifiers": {
	"email" : "jane.doe@example.com"		"email" : "jane.doe@example.com"
	},		},
	"exists" : true		"exists" : true
	},		},
	"claims" : { "oidc": { "id_token" : {} } }		"claims" : { "oidc": { "id_token" : {} } }
	}		}
	skipping to change at page 33, line 8 ¶		skipping to change at page 33, line 8 ¶
	6.1. Grant Response		6.1. Grant Response
	The Grant Response MUST include the following from the Response JSON		The Grant Response MUST include the following from the Response JSON
	Section 6.4		Section 6.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* expires_in
	and MAY include the following from the Response JSON Section 6.4		and MAY include the following from the Response JSON Section 6.4
	* authorization or authorizations		* authorization or authorizations
	* claims		* claims
			* expires_in
	Example non-normative Grant Response JSON document for Example 1 in		Example non-normative Grant Response JSON document for Example 1 in
	Section 4.1:		Section 4.1:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",		"nonce" : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
	"uri" : "https://as.example/endpoint/grant/example1",		"uri" : "https://as.example/endpoint/grant/example1",
	"expires_in" : 300		"expires_in" : 300
	"authorization": {		"authorization": {
	"type" : "oauth_scope",		"type" : "oauth_scope",
	skipping to change at page 34, line 40 ¶		skipping to change at page 34, line 40 ¶
	* wait		* wait
	A non-normative example of an Interaction Response follows:		A non-normative example of an Interaction Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example4",		"uri" : "https://as.example/endpoint/grant/example4",
	"interaction" : {		"interaction" : {
	"type" : "popup",		"type" : "redirect",
	"authorization_uri" : "https://as.example/popup/example4"		"redirect_uri" : "https://as.example/i/example4"
	},		},
	"user": {		"user": {
	"exists" : true		"exists" : true
	}		}
	}		}
	6.3. Wait Response		6.3. Wait Response
	The Wait Response MUST include the following from the Response JSON		The Wait Response MUST include the following from the Response JSON
	Section 6.4		Section 6.4
	skipping to change at page 53, line 30 ¶		skipping to change at page 53, line 30 ¶
	metadata, and the actual metadata. A .well-known discovery		metadata, and the actual metadata. A .well-known discovery
	mechanism may be defined to resolve from a hostname to the GS		mechanism may be defined to resolve from a hostname to the GS
	URI.		URI.
	16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*		16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI?*
	Maybe there are no use cases for them [that the editor knows		Maybe there are no use cases for them [that the editor knows
	of], but the GS can not implement, and they are available if use		of], but the GS can not implement, and they are available if use
	cases come up.		cases come up.
	17. *Why list explicit interactions, instead of the Client and GS
	negotiating interaction capabilities?*
	The Client knows what interactions it is capable of, and
	prefers. Telling the GS the interaction allows the GS to know
	what interaction the User will have. Knowing how the Client
	will transition the interaction will enable the GS to provider a
	better User experience. For example, the GS may want to provide
	a short URL if it knows the Client will be showing a QR code vs
	a redirect, or have a different layout if it is a popup vs a
	redirect.
	[Editor: are there use cases where the Client would want to
	provide a list of interaction types so the GS can select which
	one it can support? ]
	13. Acknowledgments		13. Acknowledgments
	This draft derives many of its concepts from Justin Richer's		This draft derives many of its concepts from Justin Richer's
	Transactional Authorization draft [TxAuth].		Transactional Authorization draft [TxAuth].
	Additional thanks to Justin Richer and Annabelle Richard Backman for		Additional thanks to Justin Richer and Annabelle Richard Backman for
	their strong critique of earlier drafts.		their strong critique of earlier drafts.
	14. IANA Considerations		14. IANA Considerations
	skipping to change at page 58, line 4 ¶		skipping to change at page 57, line 35 ¶
	* added completion_uri for code flows		* added completion_uri for code flows
	A.5. draft-hardt-xauth-protocol-04		A.5. draft-hardt-xauth-protocol-04
	* renamed interaction uris to have purpose specific names		* renamed interaction uris to have purpose specific names
	A.6. draft-hardt-xauth-protocol-05		A.6. draft-hardt-xauth-protocol-05
	* separated claims from identifiers in request user object		* separated claims from identifiers in request user object
	* simplified reciprocal grant flow		* simplified reciprocal grant flow
	* reduced interactions to redirect and indirect		* reduced interactions to redirect and indirect
	* simplified interaction parameters		* simplified interaction parameters
	* added in language for Client to verify interaction completion		* added in language for Client to verify interaction completion
	* added Verify Grant API and Interaction Nonce		* added Verify Grant API and Interaction Nonce
	* replaced Refresh AuthZ with Read AuthZ. Read and refresh are same		* replaced Refresh AuthZ with Read AuthZ. Read and refresh are same
	operation.		operation.
			A.7. draft-hardt-xauth-protocol-06
			* fixup examples to match specification
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect		Appendix B. Comparison with OAuth 2.0 and OpenID Connect
	*Changed Features*		*Changed Features*
	The major changes between this protocol and OAuth 2.0 and OpenID		The major changes between this protocol and OAuth 2.0 and OpenID
	Connect are:		Connect are:
	* The Client allows uses a private key to authenticate in this		* The Client allows uses a private key to authenticate in this
	protocol instead of the client secret in OAuth 2.0 and OpenID		protocol instead of the client secret in OAuth 2.0 and OpenID
	Connect.		Connect.
End of changes. 14 change blocks.
	35 lines changed or deleted		26 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/