< draft-hardt-xauth-protocol-03.txt		draft-hardt-xauth-protocol-04.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 18 February 2020		Intended status: Standards Track 19 February 2020
	Expires: 21 August 2020		Expires: 22 August 2020
	The XAuth Protocol		The XAuth Protocol
	draft-hardt-xauth-protocol-03		draft-hardt-xauth-protocol-04
	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 21 August 2020.		This Internet-Draft will expire on 22 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 8		3.2. Reciprocal Grant . . . . . . . . . . . . . . . . . . . . 8
	3.3. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 10		3.3. GS Initiated Grant . . . . . . . . . . . . . . . . . . . 10
	3.4. Create and Update . . . . . . . . . . . . . . . . . . . . 10		3.4. Create and Update . . . . . . . . . . . . . . . . . . . . 10
	3.5. Create and Delete . . . . . . . . . . . . . . . . . . . . 12		3.5. Create and Delete . . . . . . . . . . . . . . . . . . . . 12
	3.6. Create, Discover, and Delete . . . . . . . . . . . . . . 14		3.6. Create, Discover, and Delete . . . . . . . . . . . . . . 14
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	5.2. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 20		5.2. Read Grant . . . . . . . . . . . . . . . . . . . . . . . 20
	5.3. Update Grant . . . . . . . . . . . . . . . . . . . . . . 20		5.3. Update Grant . . . . . . . . . . . . . . . . . . . . . . 20
	5.4. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 21		5.4. Delete Grant . . . . . . . . . . . . . . . . . . . . . . 21
	5.5. Request JSON . . . . . . . . . . . . . . . . . . . . . . 22		5.5. Request JSON . . . . . . . . . . . . . . . . . . . . . . 22
	5.5.1. "client" Object . . . . . . . . . . . . . . . . . . . 22		5.5.1. "client" Object . . . . . . . . . . . . . . . . . . . 22
	5.5.2. "interaction" Object . . . . . . . . . . . . . . . . 22		5.5.2. "interaction" Object . . . . . . . . . . . . . . . . 22
	5.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 23		5.5.3. "user" Object . . . . . . . . . . . . . . . . . . . . 23
	5.5.4. "authorization" Object . . . . . . . . . . . . . . . 24		5.5.4. "authorization" Object . . . . . . . . . . . . . . . 24
	5.5.5. "authorizations" Object . . . . . . . . . . . . . . . 24		5.5.5. "authorizations" Object . . . . . . . . . . . . . . . 24
	5.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 24		5.5.6. "claims" Object . . . . . . . . . . . . . . . . . . . 24
	5.5.7. "reciprocal" Object . . . . . . . . . . . . . . . . . 25		5.5.7. "reciprocal" Object . . . . . . . . . . . . . . . . . 24
	5.6. Refresh Authorization . . . . . . . . . . . . . . . . . . 25		5.6. Refresh Authorization . . . . . . . . . . . . . . . . . . 25
	5.7. Update Authorization . . . . . . . . . . . . . . . . . . 25		5.7. Update Authorization . . . . . . . . . . . . . . . . . . 25
	5.8. Delete Authorization . . . . . . . . . . . . . . . . . . 26		5.8. Delete Authorization . . . . . . . . . . . . . . . . . . 26
	5.9. GS Options . . . . . . . . . . . . . . . . . . . . . . . 26		5.9. GS Options . . . . . . . . . . . . . . . . . . . . . . . 26
	5.10. Grant Options . . . . . . . . . . . . . . . . . . . . . . 27		5.10. Grant Options . . . . . . . . . . . . . . . . . . . . . . 27
	5.11. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 27		5.11. AuthZ Options . . . . . . . . . . . . . . . . . . . . . . 27
	5.12. Request Verification . . . . . . . . . . . . . . . . . . 28		5.12. Request Verification . . . . . . . . . . . . . . . . . . 27
	6. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 28		6. GS Initiated Grant . . . . . . . . . . . . . . . . . . . . . 28
	7. GS API Responses . . . . . . . . . . . . . . . . . . . . . . 28		7. GS API Responses . . . . . . . . . . . . . . . . . . . . . . 28
	7.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 28		7.1. Grant Response . . . . . . . . . . . . . . . . . . . . . 28
	7.2. Interaction Response . . . . . . . . . . . . . . . . . . 30		7.2. Interaction Response . . . . . . . . . . . . . . . . . . 29
	7.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 30		7.3. Wait Response . . . . . . . . . . . . . . . . . . . . . . 30
	7.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 31		7.4. Response JSON . . . . . . . . . . . . . . . . . . . . . . 31
	7.4.1. "interaction" Object . . . . . . . . . . . . . . . . 31		7.4.1. "interaction" Object . . . . . . . . . . . . . . . . 31
	7.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 32		7.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 32
	7.4.3. "authorization" Object . . . . . . . . . . . . . . . 32		7.4.3. "authorization" Object . . . . . . . . . . . . . . . 32
	7.4.4. "authorizations" Object . . . . . . . . . . . . . . . 33		7.4.4. "authorizations" Object . . . . . . . . . . . . . . . 33
	7.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 33		7.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 33
	7.4.6. "reciprocal" Object . . . . . . . . . . . . . . . . . 33		7.4.6. "reciprocal" Object . . . . . . . . . . . . . . . . . 33
	7.4.7. Interaction Types . . . . . . . . . . . . . . . . . . 34		7.4.7. Interaction Types . . . . . . . . . . . . . . . . . . 34
	7.4.8. Signing and Encryption . . . . . . . . . . . . . . . 34		7.4.8. Signing and Encryption . . . . . . . . . . . . . . . 34
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 48		15. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 48		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
	16.1. Normative References . . . . . . . . . . . . . . . . . . 48		16.1. Normative References . . . . . . . . . . . . . . . . . . 48
	16.2. Informative References . . . . . . . . . . . . . . . . . 49		16.2. Informative References . . . . . . . . . . . . . . . . . 49
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 50		Appendix A. Document History . . . . . . . . . . . . . . . . . . 50
	A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 50		A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 50
	A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 50		A.2. draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . . 50
	A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 51		A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 51
	A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51		A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51
			A.5. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 51		Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 51
	Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 52		Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 53
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
	1. Introduction		1. Introduction
	This protocol supports the widely deployed use cases supported by		This protocol supports the widely deployed use cases supported by
	OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an		OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an
	extension of OAuth 2.0, as well as other extensions, and other use		extension of OAuth 2.0, as well as other extensions, and other use
	cases that are not supported, such as acquiring multiple access		cases that are not supported, such as acquiring multiple access
	tokens at the same time, and updating the request during user		tokens at the same time, and updating the request during user
	interaction. This protocol also addresses many of the security		interaction. This protocol also addresses many of the security
	issues in OAuth 2.0 by having parameters securely sent directly		issues in OAuth 2.0 by having parameters securely sent directly
	skipping to change at page 20, line 15 ¶		skipping to change at page 20, 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",
	"uri" : "https://web.example/return"		"redirect_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 23, line 51 ¶		skipping to change at page 23, line 51 ¶
	* *identifiers* - REQUIRED if the exists attribute is present. The		* *identifiers* - REQUIRED if the exists attribute is present. The
	values MAY be used by the GS to improve the User experience.		values MAY be used by the GS to improve the User experience.
	Contains one or more of the following identifiers for the User:		Contains one or more of the following identifiers for the User:
	- *phone_number* - contains a phone number per Section 5 of		- *phone_number* - contains a phone number per Section 5 of
	[RFC3966].		[RFC3966].
	- *email* - contains an email address per [RFC5322].		- *email* - contains an email address per [RFC5322].
	- *oidc* - is an object containing both the "iss" and "sub"		- *oidc_id_token* - is an OpenID Connect ID Token per [OIDC]
	attributes from an OpenID Connect ID Token per [OIDC]
	Section 2.		Section 2.
	5.5.4. "authorization" Object		5.5.4. "authorization" Object
	* *type* - one of the following values: "oauth_scope" or		* *type* - one of the following values: "oauth_scope" or
	"oauth_rich". This attribute is REQUIRED.		"oauth_rich". This attribute is REQUIRED.
	* *scope* - a string containing the OAuth 2.0 scope per [RFC6749]		* *scope* - a string containing the OAuth 2.0 scope per [RFC6749]
	section 3.3. MUST be included if type is "oauth_scope" or		section 3.3. MUST be included if type is "oauth_scope" or
	"oauth_rich".		"oauth_rich".
	skipping to change at page 30, line 31 ¶		skipping to change at page 30, line 25 ¶
	* wait		* wait
	A non-normative example of an Interaction Response follows:		A non-normative example of an Interaction Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example4",		"uri" : "https://as.example/endpoint/grant/example4",
	"interaction" : {		"interaction" : {
	"type" : "popup",		"type" : "popup",
	"uri" : "https://as.example/popup/example4"		"authorization_uri" : "https://as.example/popup/example4"
	},		},
	"user": {		"user": {
	"exists" : true		"exists" : true
	}		}
	}		}
	7.3. Wait Response		7.3. Wait Response
	The Wait Response MUST include the following from the Response JSON		The Wait Response MUST include the following from the Response JSON
	Section 7.4		Section 7.4
	* iat		* iat
	* nonce		* nonce
	* uri		* uri
	* wait		* wait
	A non-normative example of an Wait Response follows:		A non-normative example of Wait Response follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",		"nonce" : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
	"uri" : "https://as.example/endpoint/grant/example5",		"uri" : "https://as.example/endpoint/grant/example5",
	"wait" : 300		"wait" : 300
	}		}
	7.4. Response JSON		7.4. Response JSON
	skipping to change at page 31, line 40 ¶		skipping to change at page 31, line 40 ¶
	7.4.1. "interaction" Object		7.4.1. "interaction" Object
	If the GS wants the Client to start the interaction, the GS MUST		If the GS wants the Client to start the interaction, the GS MUST
	return the interaction mechanism provided by the Client in the Grant		return the interaction mechanism provided by the Client in the Grant
	Request, and include the required attributes in the interaction		Request, and include the required attributes in the interaction
	object:		object:
	* *type* - this MUST match the type provided by the Client in the		* *type* - this MUST match the type provided by the Client in the
	Grant Request client.interaction object.		Grant Request client.interaction object.
	* *uri* - the URI to redirect the user to, load in the popup, or		* *authorization_uri* - the URI to redirect the user to or load in
	show the User to navigate to. This attribute is REQUIRED.		the popup. Must be included if type is "popup" and "redirect"
	* *qr* - the URI to show as a QR code. MUST be included if type is		* *display_uri* - the URI to be displayed to the User for them to
	"qrcode"		navigate to and enter the code. Must be included if type is
			"qrcode" and "code"
	* *code* - a text string of the code to display to the User if type		* *qr_uri* - the URI to show as a QR code. MUST be included if type
	is "qrcode" or "code".		is "qrcode"
	[Editor: do we specify a maximum length for the displayed uri and		* *user_code* - a text string of the code to display to the User.
	code so that a device knows the maximum it needs to support? A smart		Must be included if type is "qrcode" or "code".
			[Editor: do we specify a maximum length for the display_uri and code
			so that a device knows the maximum it needs to support? A smart
	device may have limited screen real estate.]		device may have limited screen real estate.]
	TBD: entropy and other security considerations for the redirect and
	popup URI, and the code.		The authorization_uri, qr_uri, and user_code MUST be unique and only
			match the associated Grant URI.
			TBD: entropy and other security considerations for the
			authorization_uri, qr_uri, and the user_code.
	See Interaction Types Section 7.4.7 for details.		See Interaction Types Section 7.4.7 for details.
	7.4.2. "user" Object		7.4.2. "user" Object
	* *exists* - a boolean value indicating if the GS has a user with		* *exists* - a boolean value indicating if the GS has a user with
	one or more of the provided identifiers in the Request		one or more of the provided identifiers in the Request
	"user"."identifiers" object Section 5.5.3		"user"."identifiers" object Section 5.5.3
	7.4.3. "authorization" Object		7.4.3. "authorization" Object
	skipping to change at page 33, line 47 ¶		skipping to change at page 34, line 4 ¶
	Response MUST contain a matching nonce attribute value.		Response MUST contain a matching nonce attribute value.
	* *client*		* *client*
	- *id* - the Client ID making the request		- *id* - the Client ID making the request
	One or more of the following objects from the Request JSON		One or more of the following objects from the Request JSON
	Section 5.5 are included:		Section 5.5 are included:
	* *authorization* Section 7.4.3		* *authorization* Section 7.4.3
	* *authorizations* Section 7.4.4		* *authorizations* Section 7.4.4
	* *claims* Section 7.4.5		* *claims* Section 7.4.5
	7.4.7. Interaction Types		7.4.7. Interaction Types
	If the GS wants the Client to initiate the interaction with the User,		If the GS wants the Client to initiate the interaction with the User,
	then the GS will return an Interaction Response. The Client will		then the GS will return an Interaction Response. The Client will
	initiate the interaction with the User in one of the following ways:		initiate the interaction with the User in one of the following ways:
	* *popup* The Client will create a new popup child browser window		* *popup* The Client will create a new popup child browser window
	with URI contained in the "interaction"."uri" attribute. [Editor:		with URI contained in the "interaction"."authorization_uri"
	more details on how to do this] The GS will close the popup window		attribute. [Editor: more details on how to do this] The GS will
	when the interactions with the User are complete. [Editor:		close the popup window when the interactions with the User are
	confirm GS can do this still on all browsers, or does Client need		complete. [Editor: confirm GS can stll do this on all browsers,
	to close?]		or does Client need to close? If so, then Client needs to provide
			a redirect_uri.]
	* *redirect* The Client will redirect the User to the		* *redirect* The Client will redirect the User to the
	"interaction"."uri" attribute. When the GS interactions with the		"interaction"."authorization_uri" attribute. When the GS
	User are complete, the GS will redirect the User to the		interactions with the User are complete, the GS will redirect the
	"interaction"."redirect_uri" attribute the Client provided in the		User to the "interaction"."redirect_uri" attribute the Client
	Grant Request.		provided in the Grant Request.
	* *qrcode* The Client will create a [QR_Code] of the		* *qrcode* The Client will create a [QR_Code] of the
	"interaction"."qr" attribute and display the resulting graphic.		"interaction"."qr" attribute and display the resulting graphic.
	The CLient will also display the "interaction"."uri" and		The Client will also display the "interaction"."display_uri" and
	"interaction"."code" per the "code" type.		"interaction"."user_code" per the "code" type.
	* *code* The Client will display the "interaction"."code" contents		* *code* The Client will display the "interaction"."user_code"
	and direct the User to navigate to the "interaction"."uri" value		contents and direct the User to navigate to the
	and enter the code.		"interaction"."display_uri" value and enter the code.
	A GS MUST support the "popup", "redirect", "qrcode", and "code"		A GS MUST support the "popup", "redirect", "qrcode", and "code"
	interaction types.		interaction types.
	[Editor: is this too restrictive?]		[Editor: is this too restrictive?]
	7.4.8. Signing and Encryption		7.4.8. Signing and Encryption
	[Editor: TBD - how response is signed and/or encrypted by the GS. Is		[Editor: TBD - how response is signed and/or encrypted by the GS. Is
	there a generalized description, or is it mechanism specific?]		there a generalized description, or is it mechanism specific?]
	skipping to change at page 51, line 36 ¶		skipping to change at page 51, line 36 ¶
	* fixed RO definition		* fixed RO definition
	* improved language in Rationals		* improved language in Rationals
	* added user code interaction method, and aligned qrcode interaction		* added user code interaction method, and aligned qrcode interaction
	method		method
	* added completion_uri for code flows		* added completion_uri for code flows
			A.5. draft-hardt-xauth-protocol-03
			* renamed interaction uris to have purpose specific names
	Appendix B. Comparison with OAuth 2.0 and OpenID Connect		Appendix B. Comparison with OAuth 2.0 and OpenID Connect
	*Changed Features*		*Changed Features*
	The major changes between this protocol and OAuth 2.0 and OpenID		The major changes between this protocol and OAuth 2.0 and OpenID
	Connect are:		Connect are:
	* The Client uses a private key to authenticate in this protocol		* The Client 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. 24 change blocks.
	43 lines changed or deleted		55 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/