< draft-hardt-xauth-protocol-02.txt   draft-hardt-xauth-protocol-03.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 8 February 2020 Intended status: Standards Track 18 February 2020
Expires: 11 August 2020 Expires: 21 August 2020
The XAuth Protocol The XAuth Protocol
draft-hardt-xauth-protocol-02 draft-hardt-xauth-protocol-03
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 11 August 2020. This Internet-Draft will expire on 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 47 skipping to change at page 2, line 47
4. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 17 4. Grant and AuthZ Life Cycle . . . . . . . . . . . . . . . . . 17
5. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. GS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Create Grant . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . 24 5.5.7. "reciprocal" Object . . . . . . . . . . . . . . . . . 25
5.6. Refresh Authorization . . . . . . . . . . . . . . . . . . 25 5.6. Refresh Authorization . . . . . . . . . . . . . . . . . . 25
5.7. Update Authorization . . . . . . . . . . . . . . . . . . 25 5.7. Update Authorization . . . . . . . . . . . . . . . . . . 25
5.8. Delete Authorization . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . 27 5.12. Request Verification . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . 29 7.2. Interaction Response . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . 31 7.4.2. "user" Object . . . . . . . . . . . . . . . . . . . . 32
7.4.3. "authorization" Object . . . . . . . . . . . . . . . 32 7.4.3. "authorization" Object . . . . . . . . . . . . . . . 32
7.4.4. "authorizations" Object . . . . . . . . . . . . . . . 32 7.4.4. "authorizations" Object . . . . . . . . . . . . . . . 33
7.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 32 7.4.5. "claims" Object . . . . . . . . . . . . . . . . . . . 33
7.4.6. "reciprocal" Object . . . . . . . . . . . . . . . . . 33 7.4.6. "reciprocal" Object . . . . . . . . . . . . . . . . . 33
7.4.7. Interaction Types . . . . . . . . . . . . . . . . . . 33 7.4.7. Interaction Types . . . . . . . . . . . . . . . . . . 34
7.4.8. Signing and Encryption . . . . . . . . . . . . . . . 34 7.4.8. Signing and Encryption . . . . . . . . . . . . . . . 34
7.5. Response Verification . . . . . . . . . . . . . . . . . . 34 7.5. Response Verification . . . . . . . . . . . . . . . . . . 34
8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. RS Access . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Bearer Token . . . . . . . . . . . . . . . . . . . . . . 35
9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 35 9. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 35
10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 35 10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . . 35
10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. GS Access . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.1. Authorization Header . . . . . . . . . . . . . . . . 36 10.1.1. Authorization Header . . . . . . . . . . . . . . . . 36
10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 37 10.1.2. Signed Body . . . . . . . . . . . . . . . . . . . . 37
10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 37 10.1.3. Public Key Resolution . . . . . . . . . . . . . . . 38
10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 38 10.2. RS Access . . . . . . . . . . . . . . . . . . . . . . . 39
10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 38 10.2.1. JOSE header . . . . . . . . . . . . . . . . . . . . 39
10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 39 10.2.2. "jose" Mechanism . . . . . . . . . . . . . . . . . . 39
10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 40 10.2.3. "jose+body" Mechanism . . . . . . . . . . . . . . . 40
10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 41 10.2.4. Public Key Resolution . . . . . . . . . . . . . . . 41
10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 41 10.3. Request Encryption . . . . . . . . . . . . . . . . . . . 42
10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 41 10.4. Response Signing . . . . . . . . . . . . . . . . . . . . 42
10.5. Response Encryption . . . . . . . . . . . . . . . . . . 42 10.5. Response Encryption . . . . . . . . . . . . . . . . . . 42
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
15. Security Considerations . . . . . . . . . . . . . . . . . . . 47 15. Security Considerations . . . . . . . . . . . . . . . . . . . 48
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
16.1. Normative References . . . . . . . . . . . . . . . . . . 47 16.1. Normative References . . . . . . . . . . . . . . . . . . 48
16.2. Informative References . . . . . . . . . . . . . . . . . 48 16.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Document History . . . . . . . . . . . . . . . . . . 49 Appendix A. Document History . . . . . . . . . . . . . . . . . . 50
A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . 50 A.3. draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . . 51
A.4. draft-hardt-xauth-protocol-03 . . . . . . . . . . . . . . 51
Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 50 Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 51
Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 51 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52
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 6, line 12 skipping to change at page 6, line 15
* *Grant Server* (GS) - manages Grants for access to APIs at RSs and * *Grant Server* (GS) - manages Grants for access to APIs at RSs and
release of identity claims about the User. The GS may require release of identity claims about the User. The GS may require
explicit consent from the RO or User to provide these to the explicit consent from the RO or User to provide these to the
Client. An GS may support Registered Clients and/or Dynamic Client. An GS may support Registered Clients and/or Dynamic
Clients. The GS is a combination of the Authorization Server (AS) Clients. The GS is a combination of the Authorization Server (AS)
in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect. in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect.
* *Resource Server* (RS) - has API resources that require an access * *Resource Server* (RS) - has API resources that require an access
token from the GS. Owned by the Resource Owner. token from the GS. Owned by the Resource Owner.
* *Resource Owner* (RO) - owns the RS, and has delegated RS access * *Resource Owner* (RO) - owns resources at the RS, and has
management to the GS. The RO may be the same entity as the User, delegated RS access management to the GS. The RO may be the same
or may be a different entity that the GS interacts with entity as the User, or may be a different entity that the GS
independently. GS and RO interactions are out of scope of this interacts with independently. GS and RO interactions are out of
document. scope of this document.
2.2. Reused Terms 2.2. Reused Terms
* *access token* - an access token as defined in [RFC6749] * *access token* - an access token as defined in [RFC6749]
Section 1.4. Section 1.4.
* *Claim* - a Claim as defined in [OIDC] Section 5. Claims may be * *Claim* - a Claim as defined in [OIDC] Section 5. Claims may be
issued by the GS, or by other issuers. issued by the GS, or by other issuers.
* *Client ID* - a GS unique identifier for a Registered Client as * *Client ID* - a GS unique identifier for a Registered Client as
skipping to change at page 22, line 49 skipping to change at page 22, line 49
The interaction object contains the type of interaction the Client The interaction object contains the type of interaction the Client
will provide the User. Other attributes will provide the User. Other attributes
* *keep* - a JSON boolean. If set to the JSON value true, the GS * *keep* - a JSON boolean. If set to the JSON value true, the GS
will not transfer the User interaction back to the Client after will not transfer the User interaction back to the Client after
processing the Grant request. The JSON value false is equivalent processing the Grant request. The JSON value false is equivalent
to the attribute not being present, and the GS will transfer the to the attribute not being present, and the GS will transfer the
User interaction back to the Client after processing the request. User interaction back to the Client after processing the request.
This attribute is OPTIONAL This attribute is OPTIONAL
- *type* - contains one of the following values: "popup", * *type* - contains one of the following values: "popup",
"redirect", or "qrcode". Details in Section 7.4.7. This "redirect", "qrcode", or "code". Details in Section 7.4.7. This
attribute is REQUIRED. attribute is REQUIRED.
- *redirect_uri* - this attribute is REQUIRED if the type is [Editor: do we want this to be an array of types the Client can
"redirect". It is the URI that the Client requests the GS to support? This would only be the case if the GS is not able to
redirect the User to after the GS has completed interacting support all types and negotiation is required. Is that required?]
with the User. If the Client manages session state in URIs,
then the redirect_uri SHOULD contain that state.
- *ui_locales* - End-User's preferred languages and scripts for * *redirect_uri* - this attribute is REQUIRED if the type is
the user interface, represented as a space-separated list of "redirect". It is the URI that the Client requests the GS to
[RFC5646] language tag values, ordered by preference. This redirect the User to after the GS has completed interacting with
attribute is OPTIONAL. the User. If the Client manages session state in URIs, then the
redirect_uri SHOULD contain that state.
* *completion_uri* - this attribute is OPTIONAL and is ignored
unless the type is "qrcode" or "code". This is the URI the Client
would like the GS to redirect the User to after the interaction
with the User is complete.
* *ui_locales* - End-User's preferred languages and scripts for the
user interface, represented as a space-separated list of [RFC5646]
language tag values, ordered by preference. This attribute is
OPTIONAL.
[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 GS, or max specified values here?] Either passed to GS, 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.]
skipping to change at page 31, line 33 skipping to change at page 31, line 33
* *wait* - a numeric value representing the number of seconds the * *wait* - a numeric value representing the number of seconds the
Client should want before making a Read Grant request to the Grant Client should want before making a Read Grant request to the Grant
URI. URI.
* *expires_in* - a numeric value specifying how many seconds until * *expires_in* - a numeric value specifying how many seconds until
the Grant expires. This attribute is OPTIONAL. the Grant expires. This attribute is OPTIONAL.
7.4.1. "interaction" Object 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
select one of the interaction mechanisms provided by the Client in return the interaction mechanism provided by the Client in the Grant
the Grant Request, and include the matching attribute in the Request, and include the required attributes 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
Grant Request client.interaction object. Grant Request client.interaction object.
* *uri* - the URI to interact with the User per the type. This may * *uri* - the URI to redirect the user to, load in the popup, or
be a temporary short URL if the type is qrcode so that it is easy show the User to navigate to. This attribute is REQUIRED.
to scan.
* *message* - a text string to display to the User if type is * *qr* - the URI to show as a QR code. MUST be included if type is
qrcode. "qrcode"
[Editor: do we specify a maximum length for the uri and message so * *code* - a text string of the code to display to the User if type
that a device knows the maximum it needs to support? A smart device is "qrcode" or "code".
may have limited screen real estate.]
[Editor: do we specify a maximum length for the displayed uri and
code so that a device knows the maximum it needs to support? A smart
device may have limited screen real estate.]
TBD: entropy and other security considerations for the redirect and
popup URI, and the code.
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
The "authorization" object is a response to the Request The "authorization" object is a response to the Request
"authorization" object Section 5.5.4, the Refresh Authorization "authorization" object Section 5.5.4, the Refresh Authorization
Section 5.6, or the Update Authorization Section 5.7. Section 5.6, or the Update Authorization Section 5.7.
skipping to change at page 33, line 49 skipping to change at page 34, line 12
* *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
containing the "interaction"."uri" attribute. [Editor: more with URI contained in the "interaction"."uri" attribute. [Editor:
details on how to do this] more details on how to do this] The GS will close the popup window
when the interactions with the User are complete. [Editor:
The GS will close the popup window when the interactions with the confirm GS can do this still on all browsers, or does Client need
User are complete. [Editor: confirm GS can do this still on all to close?]
browsers, or does Client need to close]
* *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"."uri" attribute. When the GS interactions with the
User are complete, the GS will redirect the User to the User are complete, the GS will redirect the User to the
"interaction"."redirect_uri" attribute the Client provided in the "interaction"."redirect_uri" attribute the Client provided in the
Grant Request. Grant Request.
* *qrcode* The Client will create a [QR_Code] of the * *qrcode* The Client will create a [QR_Code] of the
"interaction"."uri" attribute and display the resulting graphic "interaction"."qr" attribute and display the resulting graphic.
and the "interaction"."message" attribute as a character string. The CLient will also display the "interaction"."uri" and
"interaction"."code" per the "code" type.
An GS MUST support the "popup", "redirect", and "qrcode" interaction * *code* The Client will display the "interaction"."code" contents
types. and direct the User to navigate to the "interaction"."uri" value
and enter the code.
A GS MUST support the "popup", "redirect", "qrcode", and "code"
interaction types.
[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?]
7.5. Response Verification 7.5. Response Verification
On receipt of a response, the Client MUST verify the following: On receipt of a response, the Client MUST verify the following:
skipping to change at page 45, line 4 skipping to change at page 45, line 16
having to manage a separate access token and refresh token. If having to manage a separate access token and refresh token. If
the Client would like additional claims, it can Update Grant, the Client would like additional claims, it can Update Grant,
and the GS will let the Client know if an interaction is and the GS will let the Client know if an interaction is
required to get any of the additional claims, which the Client required to get any of the additional claims, which the Client
can then start. can then start.
[Editor: is there some other reason to have the UserInfo [Editor: is there some other reason to have the UserInfo
endpoint?] endpoint?]
7. *Why is there still a Client ID?* 7. *Why is there still a Client ID?*
The GS needs an identifier to fetch the meta data associated The GS needs an identifier to fetch the meta data associated
with a Client such as the name and image to display to the User, with a Client such as the name and image to display to the User,
and the policies on what a Client is allowed to do. The Client and the policies on what a Client is allowed to do. The Client
ID was used in OAuth 2.0 for the same purpose, which simplifies ID was used in OAuth 2.0 for the same purpose, which simplifies
migration. Dynamic Clients do not have a Client ID. migration. Dynamic Clients do not have a Client ID.
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 and providing claims vs granting access to
request for an authorization returns an access token or handle, a resource. A request for an authorization returns an access
while a request for a claim returns the claim. token which may have full CRUD capabilities, while a request for
a claim returns the claim about the User - with no create,
update or delete capabilities. While the UserInfo endpoint in
OIDC may be thought of as a resource, separating the concepts
and how they are requested keeps each of them simpler in the
Editor's opinion. :)
9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and 9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and
GS communication in ?*Section 10 GS communication in ?*Section 10
Knowing the GS supports HTTP/2 enables a Client to set up a Knowing the GS 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 GS as there will be less network traffic. refreshing them at the GS 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 GS when setting up a TLS connection. security of Clients and GS when setting up a TLS connection.
skipping to change at page 45, line 42 skipping to change at page 46, line 13
and a convoluted extension. and a convoluted extension.
11. *Why is the "iss" included in the "oidc" identifier object? 11. *Why is the "iss" included in the "oidc" identifier object?
Would the "sub" not be enough for the GS to identify the User?* Would the "sub" not be enough for the GS to identify the User?*
This decouples the GS from the OpenID Provider (OP). The GS This decouples the GS from the OpenID Provider (OP). The GS
identifier is the GS URI, which is the endpoint at the GS. The identifier is the GS URI, which is the endpoint at the GS. The
OP issuer identifier will likely not be the same as the GS URI. OP issuer identifier will likely not be the same as the GS URI.
The GS may also provide claims from multiple OPs. The GS may also provide claims from multiple OPs.
12. *Why complicate the sequence with "interaction"."keep"?* 12. *Why complicate things with "interaction"."keep"?*
A common pattern is to use an GS to authenticate the User at the The common sequence has a back and forth between the Client and
Client. The Client does not know a priori if the User is a new the GS, and the Client can update the Grant and have a new
interaction. Keeping the interaction provides a more seamless
user experience where the results from the first request
determine subsequent requests. For example, a common pattern is
to use a GS to authenticate the User at the Client, and to
register the User at the Client using additional claims from the
GS. The Client does not know a priori if the User is a new
User, or a returning User. Asking a returning User to consent User, or a returning User. Asking a returning User to consent
releasing identity claims and/or authorizations they have releasing claims they have already provided is a poor User
already provided is a poor User experience, as is sending the experience, as is sending the User back to the GS. The Client
User back to the GS. The Client requesting identity first requesting identity first enables the Client to get a response
enables the Client to get a response from the GS while the GS is from the GS while the GS is still interacting with the User, so
still interacting with the User, so that the Client can request that the Client can request additional claims only if needed.
any identity claims/or authorizations required or desired.
Additionally, the claims a Client may want about a User may be Additionally, the claims a Client may want about a User may be
dependent on some initial Claims. For example, if a User is in dependent on some initial Claims. For example, if a User is in
a particular country, additional or different Claims my be a particular country, additional or different Claims my be
required by the Client required by the Client.
There are also benefits for the GS. Today, a GS usually keeps
track of which claims a Client has requested for a User.
Storing this information for all Clients a User uses may be
undesirable for a GS that does not want to have that information
about the User. Keeping the interaction allows the Client to
track what information it has about the User, and the GS can
remain stateless.
13. *Why is there a "jose+body" RS access mechanism method for the 13. *Why is there a "jose+body" RS access mechanism method for the
Client?*Section 10.2.3 Client?*Section 10.2.3
There are numerous use cases where the RS wants non-repudiation There are numerous use cases where the RS wants non-repudiation
and providence of the contents of an API call. For example, the and providence of the contents of an API call. For example, the
UGS Service Supplier Framework for Authentication and UGS Service Supplier Framework for Authentication and
Authorization [UTM]. Authorization [UTM].
14. *Why use URIs to instead of handles for the Grant and 14. *Why use URIs to instead of handles for the Grant and
skipping to change at page 46, line 20 skipping to change at page 47, line 4
13. *Why is there a "jose+body" RS access mechanism method for the 13. *Why is there a "jose+body" RS access mechanism method for the
Client?*Section 10.2.3 Client?*Section 10.2.3
There are numerous use cases where the RS wants non-repudiation There are numerous use cases where the RS wants non-repudiation
and providence of the contents of an API call. For example, the and providence of the contents of an API call. For example, the
UGS Service Supplier Framework for Authentication and UGS Service Supplier Framework for Authentication and
Authorization [UTM]. Authorization [UTM].
14. *Why use URIs to instead of handles for the Grant and 14. *Why use URIs to instead of handles for the Grant and
Authorization?* Authorization?*
A URI is an identifier just like a handle that can contain GS A URI is an identifier just like a handle that can contain GS
information that is opaque to the Client - so it has all the information that is opaque to the Client - so it has all the
features of a handle, plus it can be the URL that is resolved to features of a handle, plus it can be the URL that is resolved to
manipulate a Grant or an Authorization. As the Grant URI and manipulate a Grant or an Authorization. As the Grant URI and
AuthZ URI are defined to start with the GS URI, the Client (and AuthZ URI are defined to start with the GS URI, the Client (and
GS) can easily determine which GS a Grant or Authorization GS) can easily determine which GS a Grant or Authorization
belong to. URIs also enable a RESTful interface to the GS belong to. URIs also enable a RESTful interface to the GS
functionality. functionality.
15. *Why have an OPTIONS verb on the GS URI? Why not use a .well- 15. *Why use the OPTIONS verb on the GS URI? Why not use a .well-
known mechanism?* known mechanism?*
Having the GS URI endpoint respond to the metadata allows the GS Having the GS URI endpoint respond to the metadata allows the GS
to provide Client specific results using the same Client to provide Client specific results using the same Client
authentication used for other requests to the GS. It also authentication used for other requests to the GS. It also
reduces the risk of a mismatch between what the advertised reduces the risk of a mismatch between what the advertised
metadata, and the actual metadata. A .well-known discovery metadata, and the actual metadata. A .well-known discovery
mechanism may be defined to resolve from a hostname to the GS mechanism may be defined to resolve from a hostname to the GS
URI. URI.
16. *Why have an UPDATE, DELETE, and OPTIONS verbs on the AuthZ 16. *Why support UPDATE, DELETE, and OPTIONS verbs on the AuthZ
URI?* URI?*
Maybe there are no use cases for them [that the editor knows Maybe there are no use cases for them [that the editor knows
of], but the GS can not implement, and they are available if use of], but the GS can not implement, and they are available if use
cases come up. cases come up.
17. *Why list explicit interactions, instead of the Client and GS 17. *Why list explicit interactions, instead of the Client and GS
negotiating interaction capabilities?* negotiating interaction capabilities?*
The Client knows what interactions it is capable of, and The Client knows what interactions it is capable of, and
prefers. Telling the GS the interaction allows the GS to know prefers. Telling the GS the interaction allows the GS to know
what interaction the User will have. Knowing how the Client what interaction the User will have. Knowing how the Client
will transition the interaction will enable the GS to provider a will transition the interaction will enable the GS to provider a
better User experience. For example, the GS may want to provide 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 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 a redirect, or have a different layout if it is a popup vs a
redirect. 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 for his strong critique of earlier Additional thanks to Justin Richer and Annabelle Richard Backman for
drafts. their strong critique of earlier drafts.
14. IANA Considerations 14. IANA Considerations
[ JOSE parameter for Authorization HTTP header ] [ JOSE parameter for Authorization HTTP header ]
TBD TBD
15. Security Considerations 15. Security Considerations
TBD TBD
skipping to change at page 50, line 16 skipping to change at page 51, line 4
* text clean up * text clean up
* added OIDC4IA claims * added OIDC4IA claims
* added "jws" method for accessing a resource. * added "jws" method for accessing a resource.
* renamed Initiation Request -> Grant Request * renamed Initiation Request -> Grant Request
* renamed Initiation Response -> Interaction Response * renamed Initiation Response -> Interaction Response
* renamed Completion Request -> Authorization Request * renamed Completion Request -> Authorization Request
* renamed Completion Response -> Grant Request * renamed Completion Response -> Grant Request
* renamed completion handle -> authorization handle * renamed completion handle -> authorization handle
* added Authentication Request, Authentication Response, * added Authentication Request, Authentication Response,
authentication handle authentication handle
A.3. draft-hardt-xauth-protocol-02 A.3. draft-hardt-xauth-protocol-02
* handles are now URIs * major rewrite
* the * handles are now URIs
* the collection of claims and authorizations are a Grant * the collection of claims and authorizations are a Grant
* an Authorization is its own type
* lots of sequences added
A.4. draft-hardt-xauth-protocol-03
* fixed RO definition
* improved language in Rationals
* added user code interaction method, and aligned qrcode interaction
method
* added completion_uri for code flows
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. 46 change blocks. 
93 lines changed or deleted 152 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/