draft-ietf-oauth-dyn-reg-00.txt   draft-ietf-oauth-dyn-reg-01.txt 
Network Working Group T. Hardjono, Ed. Network Working Group J. Richer, Ed.
Internet-Draft MIT Internet-Draft The MITRE Corporation
Intended status: Standards Track M. Machulak Intended status: Standards Track T. Hardjono
Expires: November 24, 2012 Newcastle University Expires: May 9, 2013 MIT
M. Machulak
Newcastle University
E. Maler E. Maler
XMLgrrl.com XMLgrrl.com
C. Scholz C. Scholz
COM.lounge GmbH COM.lounge GmbH
May 23, 2012 N. Sakimura
NRI
J. Bradley
Ping Identity
M. Jones
Microsoft
November 5, 2012
OAuth Dynamic Client Registration Protocol OAuth Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-00 draft-ietf-oauth-dyn-reg-01
Abstract Abstract
This specification proposes an OAuth Dynamic Client Registration This specification proposes an OAuth Dynamic Client Registration
protocol. protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 24, 2012. This Internet-Draft will expire on May 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. The client needs to be uniquely identifiable by
3.1. The client needs to be uniquely identifiable by the the authorization server . . . . . . . . . . . . . . . 4
authorization server . . . . . . . . . . . . . . . . . . . 5 1.3.2. The authorization server must collect metadata
3.2. The authorization server must collect metadata about a about a client for later user interaction . . . . . . 4
client for later user interaction . . . . . . . . . . . . 5 1.3.3. The authorization server should have the option of
3.3. The authorization server must have the option of strongly authenticating the client and its metadata . 4
strongly authenticating the client and its metadata . . . 5 1.3.4. Dynamic client registration must be possible from
3.4. Dynamic client registration must be possible from both both web-server applications and applications with
web-server applications and applications with other other capabilities and limitations, such as native
capabilities and limitations, such as native applications . . . . . . . . . . . . . . . . . . . . . 4
applications . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.5. Transaction integrity must be ensured . . . . . . . . 5
3.5. Transaction integrity must be ensured in large 2. Client Registration Endpoint . . . . . . . . . . . . . . . . . 5
deployments where data propagation can be an issue . . . . 6 2.1. Client Association Request . . . . . . . . . . . . . . . . 6
3.6. Use of standardized discovery protocol . . . . . . . . . . 6 2.2. Client Association Response . . . . . . . . . . . . . . . 8
3.7. UMA design principles and requirements . . . . . . . . . . 7 2.3. Client Update Request . . . . . . . . . . . . . . . . . . 9
4. Analysis of Registration Flow Options . . . . . . . . . . . . 7 2.4. Client Update Response . . . . . . . . . . . . . . . . . . 10
5. Client Registration with Pushed Metadata . . . . . . . . . . . 8 2.5. Rotate Secret Request . . . . . . . . . . . . . . . . . . 11
5.1. Client Registration Request . . . . . . . . . . . . . . . 9 2.6. Rotate Secret Response . . . . . . . . . . . . . . . . . . 11
5.2. Client Registration Response . . . . . . . . . . . . . . . 10 2.7. Client Registration Error Response . . . . . . . . . . . . 12
5.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 11 3. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13
6. Client Registration with Pushed URL and Pulled Metadata . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Client Registration Request . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.2. Client Discovery . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Client Registration Response . . . . . . . . . . . . . . . 13 7. Document History . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Error Response . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Native Application Client Registration . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Document History . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Non-Normative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This draft discusses a number of requirements for and approaches to In some use-case scenarios, it is desirable or necessary to allow
automatic registration of clients with an OAuth authorization server,
with special emphasis on the needs of the OAuth-based User-Managed
Access protocol [UMA-Core]. This draft also proposes a dynamic
registration protocol for an OAuth authorization server.
In some use-case scenarios it is desirable or necessary to allow
OAuth clients to obtain authorization from an OAuth authorization OAuth clients to obtain authorization from an OAuth authorization
server without the two parties having previously interacted. server without the two parties having previously interacted.
Nevertheless, in order for the authorization server to accurately Nevertheless, in order for the authorization server to accurately
represent to end-users which client is seeking authorization to represent to end-users which client is seeking authorization to
access the end-user's resources, a method for automatic and unique access the end-user's resources, a method for automatic and unique
registration of clients is needed. registration of clients is needed. The OAuth2 authorization
framework does not define how the relationship between the Client and
The goal of this proposed registration protocol is for an the Authorization Server is initialized, or how a given client is
authorization server to provide a client with a client identifier and assigned a unique Client Identifier. Historically, this has happened
optionally a client secret in a dynamic fashion. To accomplish this, out-of-band from the OAuth protocol. This draft provides a mechanism
the authorization server must first be provided with information for a client to register itself with the Authorization Server, which
about the client, with the client-name being the minimal information can be used to dynamically provision a Client Identifier, and
provided. In practice, additional information will need to be optionally a Client Secret.
furnished to the authorization server, such as the client's homepage,
icon, description, and so on.
The dynamic registration protocol proposed here is envisioned to be As part of the registration process, this specification also defines
an additional task to be performed by the OAuth authorization server, a mechanism for the client to present the Authorization Server with a
namely registration of a new client identifier and optional secret set of meta information, such as a display name and icon to be
and the issuance of this information to the client. This task would presented to the user during the authorization step. This draft
occur prior to the point at which the client wields its identifier provides a method for the client to register and update this
and secret at the authorization server in order to obtain an access information over time.
token in normal OAuth fashion.
1.1. Notational Conventions 1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
1.2. Terminology 1.2. Terminology
resource server
A server capable of accepting and responding to protected
resource requests.
resource owner
An entity capable of granting access to a protected resource.
client This specification uses the terms "Access Token", "Refresh Token",
An application obtaining authorization and making protected "Authorization Code", "Authorization Grant", "Authorization Server",
resource requests. "Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server",
authorization server and "Token Endpoint" defined by OAuth 2.0 [OAuth2.0].
A server capable of issuing tokens after successfully
authenticating the resource owner and obtaining authorization.
The authorization server may be the same server as the resource
server, or a separate entity.
authorization manager
An UMA-defined variant of an authorization server that carries
out an authorizing user's policies governing access to a
protected resource.
end-user authorization endpoint
The authorization server's HTTP endpoint capable of
authenticating the end-user and obtaining authorization.
token endpoint
The authorization server's HTTP endpoint capable of issuing
tokens and refreshing expired tokens.
client identifier
An unique identifier issued to the client to identify itself to
the authorization server. Client identifiers may have a
matching secret.
client registration endpoint The authorization server's HTTP
endpoint capable of issuing client identifiers and optional
client secrets.
2. Use Cases
The UMA protocol involves two instances of OAuth flows. In the This specification defines the following additional terms:
first, an end-user introduces a host (essentially an enhanced OAuth
resource server) to an authorization manager (an enhanced OAuth
authorization server) as a client of it, possibly without that host
having obtained client identification information from that server
previously. In the second, a requester (an enhanced OAuth client)
approaches a host and authorization manager to get and use an access
token in approximately the normal OAuth fashion, again possibly
without that client having obtained client identification information
from that server previously. Both the host-as-client and the
requester-as-client thus may need dynamic client registration in
order for the UMA protocol flow to proceed.
The needs for inter-party trust vary in different UMA use cases. In o Client Registration Endpoint: The OAuth 2.0 Endpoint through which
lightweight Web circumstances such as person-to-person calendar a Client can request new registration and manage the metadata
sharing, dynamic registration is entirely appropriate. In cases associated with it.
where high-sensitivity information is being protected or where a
regulatory environment puts constraints on the building of trust
relationships, such as sharing health records with medical
professionals or giving access to tax records to outsourced
bookkeeping staff, static means of provisioning client identifiers
may be imposed.
More information about UMA use cases is available at [UMA-UC]. o Registration Access Token: An OAuth 2.0 Bearer Token issued by the
Authorization Server through the Client Registration Endpoint
which is used by the Client to authenticate itself during update
and secret rotation operations.
3. Requirements 1.3. Requirements
Following are proposed requirements for dynamic client registration. [[ Following are proposed requirements for dynamic client
registration. This section is intended for discussion and will
likely be removed in the final draft. ]]
3.1. The client needs to be uniquely identifiable by the authorization 1.3.1. The client needs to be uniquely identifiable by the
server authorization server
In order for an authorization server to do proper user-delegated In order for an authorization server to do proper user-delegated
authorization and prevent unauthorized access it must be able to authorization and prevent unauthorized access it must be able to
identify clients uniquely. As is done today in OAuth, the client identify clients uniquely. As is done today in OAuth, the client
identifier (and optional secret) should thus be issued by the identifier (and optional secret) should thus be issued by the
authorization server and not simply accepted as proposed by the authorization server and not simply accepted as proposed by the
client. client.
3.2. The authorization server must collect metadata about a client for 1.3.2. The authorization server must collect metadata about a client
later user interaction for later user interaction
In order for the authorization server to describe a client to an end- In order for the authorization server to describe a client to an end-
user in an authorization step it needs information about the client. user in an authorization step it needs information about the client.
This can be the client name at a minimum, but today servers usually This can be the client name at a minimum, but today servers usually
request at least a description, a homepage URL, and an icon when request at least a description, a homepage URL, and an icon when
doing manual registration. doing manual registration.
3.3. The authorization server must have the option of strongly 1.3.3. The authorization server should have the option of strongly
authenticating the client and its metadata authenticating the client and its metadata
In order to prevent spoofing of clients and enable dynamic building In order to prevent spoofing of clients and enable dynamic building
of strong trust relationships, the authorization server should have of strong trust relationships, the authorization server should have
the option to verify the provided information. This might be solved the option to verify the provided information. This might be solved
using message signature verification; relatively weaker using message signature verification.
authentication might be achieved in a simpler way by pulling metadata
from a trusted client URL.
3.4. Dynamic client registration must be possible from both web-server 1.3.4. Dynamic client registration must be possible from both web-
applications and applications with other capabilities and server applications and applications with other capabilities and
limitations, such as native applications limitations, such as native applications
In the UMA context, alternative types of applications might serve as Each instance of a native application (that is, the specific instance
both hosts (for example, as a device-based personal data store) and running on each device) that is installed and run by the same user
requesters (for example, to subscribe to a calendar or view a photo). may need the option of getting a unique client identifier. In this
Such applications, particularly native applications, may have special case, there are implications around gathering and displaying enough
limitations, so new solutions to meeting the set of requirements information to ensure that the end-user is delegating authorization
presented here may be needed. We anticipate that each instance of a to the intended application. The registration protocol should be
native application (that is, the specific instance running on each simple and flexible enough to allow for multiple types of
device) that is installed and run by the same user may need the applications.
option of getting a unique client identifier. In this case, there
are implications around gathering and displaying enough information
to ensure that the end-user is delegating authorization to the
intended application.
3.5. Transaction integrity must be ensured in large deployments where 1.3.5. Transaction integrity must be ensured
data propagation can be an issue
When a client sends information to a server endpoint, it might take When a client sends information to a server endpoint, it might take
time for this data to propagate through big server installations that time for this data to propagate through big server installations that
spread across various data centers. Care needs to be taken that spread across various data centers. Care needs to be taken that
subsequent interactions with the user after the registration process, subsequent interactions with the user after the registration process,
such as an authorization request, show the correct data. such as an authorization request, show the correct data.
In the UMA context, dynamic registration of a host at an AM is almost 2. Client Registration Endpoint
certain to take place in the middle of an introduction and
authorization process mediated by the end-user; even though the host
needs a client identifier from the AM no matter which end-user caused
the registration process to take place, the end-user may need to wait
for the registration sub-process to finish in order to continue with
the overall process. It may be necessary to ensure that the host
interacts with the same AM server throughout.
3.6. Use of standardized discovery protocol The Client Registration Endpoint is an OAuth 2.0 Endpoint defined in
this document that is designed to allow a Client to register itself
with the Authorization Server. The Client Registration Endpoint MUST
accept HTTP POST messages with request parameters encoded in the
entity body using the "application/x-www-form-urlencoded" format.
The Client Registration Endpoint MUST be protected by a transport-
layer security mechanism when sending requests to the Registration
Endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or
TLS 1.0 [RFC2246] and MAY support additional transport-layer
mechanisms meeting its security requirements. When using TLS, the
Client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125].
Regardless of flow option, the client needs to discover the The Endpoint defines three operations that a client can take on it,
authorization server's client registration endpoint. The client MUST switched by the "operation" parameter:
use the [RFC5785] and [hostmeta] discovery mechanisms to learn the
URI of the client registration endpoint at the authorization server.
The authorization server MUST provide a host-meta document that
clearly defines the registration end-point at the server.
3.7. UMA design principles and requirements o client_associate: generate a new Client Identifier (and optionally
a Client Secret) and associate it with the set of presented
metadata (Section 3)
In addition to general requirements for dynamic client registration, o client_update: update the metadata (Section 3) associated with a
UMA seeks to optimize for the design principles and requirements Client Identifier
found in the UMA Requirements document [UMA-Reqs], most particularly:
o DP1: Simple to understand, implement in an interoperable fashion, o rotate_secret: issue a new Registration Access Token and, if
and deploy on an Internet-wide scale applicable, a Client Secret for a Client
o DP6: Able to be combined and extended to support a variety of use In order to facilitate registered clients updating their information,
cases and emerging application functionality the Client Registration Endpoint issues a request_access_token for
clients to securely identify themselves in future connections. As
such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens
[OAuth.Bearer] for these operations.
o DP8: Avoid adding crypto requirements beyond what existing web app In order to support open registration and facilitate wider
implementations do today interoperability, the Client Registration Endpoint SHOULD allow
client_associate requests with no further authentication. These
requests MAY be rate-limited to prevent a denial-of-service attack on
the Client Registration Endpoint.
o DP10: Complexity should be borne by the authorization endpoint vs. In addition, the Client Registration Endpoint MAY accept an initial
other endpoints authorization credential in the form of an OAuth 2.0 [OAuth2.0]
access token in order to limit registration to only previously
authorized parties. The method by which this access token is
obtained by the registrant is generally out-of-band and is out of
scope of this specification.
4. Analysis of Registration Flow Options These two aspects, operation selection and client authentication, are
represented by two parameters common to all operations:
This section analyzes some options for exchanging client metadata for operation REQUIRED. Values are "client_associate" (for new
a client identifier and optional secret. registrations), "rotate_secret" to request rotation of the
"client_secret", and "client_update" (for updating parameters of
an existing "client_id").
It currently seems impossible to specify a single registration flow access_token OPTIONAL. An OAuth2 Bearer token used to access the
that will satisfy all requirements, deployment needs, and client Client Registration Endpoint, as defined in OAuth2 Bearer. This
types. This document, therefore, presents as small a variety of parameter MUST NOT be sent if the Access Token is sent in the HTTP
options as possible. If it is possible to construct a single unified Authorization header as described in Section 7.1 of OAuth 2.0
flow in the ultimate design, all other things being equal this would [OAuth2.0]. Access Tokens sent in the authorization header must
be preferred. be OAuth 2.0 Bearer Tokens [OAuth.Bearer].
Client provides metadata on every request Each operation takes a different parameter set, and all operations
In this approach, the client passes all necessary metadata such are described below.
as its name and icon on every request to the authorization
server, and the client doesn't wield a client identifier as
such. This option makes it more difficult (though not
impossible) to meet the first and second requirements since
different clients could theoretically represent themselves to
an authorization server with the same metadata and the same
client could represent itself on subsequent visits with
different metadata. Also, today's OAuth protocol requires the
use of a client identifier. Because of the UMA simplicity
principle we do not recommend this flow option and and have not
provided a candidate solution.
Client pushes metadata The Client Registration Endpoint MUST ignore all parameters it does
In this approach, the client discovers the registration not understand.
endpoint of the authorization server and sends its metadata
directly to that endpoint in a standard format. The
authorization server answers with a client identifier and
optional secret in the response. This approach may be
necessary in cases where the client is behind a firewall, but
strong authentication of the client metadata may be more
difficult or costly with this approach than with a "pull"
approach, discussed just below. Further, this approach is
problematic in the case of applications that can't function as
POST-capable web servers. A proposal for "push" is presented
in this document.
Client pushes URL, server pulls metadata from it 2.1. Client Association Request
In this approach, the client sends only a URL to the
authorization server, which then uses that URL to pull metadata
about the client in some standard format, returning
identification information in the response to the initial
request. This approach more easily allows for strong
authentication of clients because the metadata can be
statically signed. (The message containing the URL could be
signed as well.) However, caution should be exercised around
the propagation issue if the initial URL push is made to a
server different from the one the end-user is interacting with.
Further, this approach is problematic in the case of
applications that cannot themselves serve as "pull-able"
metadata repositories. A proposal for "pull" is presented in
this document.
Native-app client collaborates with home-base web app to provide This operation registers a new client to the Authorization Server.
metadata The Authorization Server assigns this client a unique Client
An instance of a native application (for example, on a mobile Identifier, optionally assigns a Client Secret, and associates the
device) may have difficulty directly conveying trustworthy metadata given in the request with the issued Client Identifier. The
metadata but may also have difficulty providing a trustworthy request includes the two parameters described above as well as any
third-party source from which a server can pull metadata. This parameters described in Client Metadata (Section 3).
document explores one option for meeting the requirements, but
does not present a full-fledged proposal.
5. Client Registration with Pushed Metadata operation REQUIRED, MUST have the value "client_associate"
This registration flow works as follows: access_token OPTIONAL, used to restrict new client registration
redirect_uris
REQUIRED
1. The client sends its metadata in JSON form to the client client_name RECOMMENDED
registration endpoint. The client MUST send its name,
description, and redirection URI and MAY send a URI for its icon.
The client MAY sign the metadata as a JSON Token issuer, using
the mechanisms defined in [OAuth-Sig].
2. The authorization server checks the data, verifying the signature client_url
as necessary, and returns a client identifier and an optional RECOMMENDED
client secret.
+--------+ +---------------+ logo_url OPTIONAL
| Client |--(A)--- Registration Request --->| Authorization |
| | with Metadata | Server |
| | | |
| |<-(B)----Registration Response ---| |
| | with Client ID Info | |
+--------+ +---------------+
Figure 1: Client Registration Flow with Pushed Metadata contacts OPTIONAL
5.1. Client Registration Request tos_url OPTIONAL
The client sends a JSON formatted document to the client registration token_endpoint_auth_method OPTIONAL
endpoint. The client includes the following parameters in the
request:
type policy_url OPTIONAL
REQUIRED. This parameter must be set to "push".
client_name jwk_url OPTIONAL
REQUIRED. This field contains a human-readable name of the
client.
client_url jwk_encryption_url OPTIONAL
REQUIRED. This field contains the URL of the homepage of the
client.
client_description x509_url OPTIONAL
REQUIRED. This field contains a text description of the
client.
client_icon x509_encryption_url OPTIONAL
OPTIONAL. This field contains a URL for an icon for the
client.
redirect_url require_signed_request_object OPTIONAL
REQUIRED. This field contains the URL to which the
authorization server should send its response.
The client MAY include additional metadata in the request and the default_max_age OPTIONAL
authorization server MAY ignore this additional information.
For example, the client might send the following request: default_acr OPTIONAL
POST /register HTTP/1.1 For example, a client could send the following registration request
Host: server.example.com to the Client Registration Endpoint:
Content-Type: application/json
{ Following is a non-normative example request (with line wraps for
type: "push", display purposes only):
client_name: "Online Photo Gallery", POST /register HTTP/1.1
client_url: "http://onlinephotogallery.com", Accept: application/x-www-form-urlencoded
client_description: "Uploading and also editing capabilities!", Host: server.example.com
client_icon: "http://onlinephotogallery.com/icon.png", Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
redirect_url: "https://onlinephotogallery.com/client_reg"
}
The parameters are included in the entity body of the HTTP request operation=client_associate
using the "application/json" media type as defined by [JSON]. The &redirect_uris=https://client.example.org/callback
parameters are serialized into a JSON structure by adding each %20https://client.example.org/callback2
parameter at the highest structure level. Parameter names and string &client_name=My%20Example%20
values are included as JSON strings. &logo_url=https://client.example.org/logo.png
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
5.2. Client Registration Response 2.2. Client Association Response
After receiving and verifying information received from the client, Upon successful association, the Client Registration Endpoint returns
the authorization server issues a client identifier and an optional the newly-created Client Identifier and, optionally, a Client Secret.
client secret, and constructs the response by adding the following The response also contains a Registration Access Token that is to be
parameters to the entity body of the HTTP response with a 200 status used by the client to perform subsequent operations at this endpoint.
code (OK): These items are returned as a JSON document with the following fields
as top-level members of the root JSON object.
client_id client_id REQUIRED. The unique Client identifier, MUST NOT be
REQUIRED. currently valid for any other registered Client.
client_secret client_secret OPTIONAL. The Client secret. This MUST be unique for
OPTIONAL. each "client_id". This value us used by confidential clients. It
is not required for clients selecting a token_endpoint_auth_type
of "private_key_jwt"
registration_access_token REQUIRED The Access token to be used by
the client to perform "client_update" and "rotate_secret"
requests.
issued_at issued_at
OPTIONAL. Specifies the timestamp when the identifier was OPTIONAL. Specifies the timestamp when the identifier was issued.
issued. The timestamp value MUST be a positive integer. The The timestamp value MUST be a positive integer. The value is
value is expressed in the number of seconds since January 1, expressed in the number of seconds since January 1, 1970 00:00:00
1970 00:00:00 GMT. GMT.
expires_in expires_at OPTIONAL. The number of seconds from 1970-01-01T0:0:0Z
OPTIONAL; if supplied, the "issued_at" parameter is REQUIRED. as measured in UTC that the "client_secret" will expire or "0" if
Specifies the valid lifetime, in seconds, of the identifier. they do not expire. See RFC 3339 [RFC3339] for details regarding
The value is represented in base 10 ASCII. date/times in general and UTC in particular.
The parameters are included in the entity body of the HTTP response Following is a non-normative example response:
using the "application/json" media type as defined by [JSON]. The HTTP/1.1 200 OK
parameters are serialized into a JSON structure by adding each Content-Type: application/json
parameter at the highest structure level. Parameter names and string Cache-Control: no-store
values are included as JSON strings.
The authorization server MUST include the HTTP "Cache-Control" {
response header field with a value of "no-store" in any response "client_id":"s6BhdRkqt3",
containing "client_secret". "client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"registration_access_token": "this.is.a.access.token.value.ffx83",
"expires_at":2893276800
}
For example, the authorization server might return the following 2.3. Client Update Request
response:
HTTP/1.1 200 OK This operation updates a previously-registered client with new
Content-Type: application/json metadata at the Authorization Server. This request MUST be protected
Cache-Control: no-store by the Registration Authorization Token associated with the Client
Identifier. This request MAY include any fields described in Client
Metadata (Section 3). The values of Client Metadata fields in this
request MUST replace (not augment) the values previously associated
with this client_identifier. Empty values in Client Metadata SHOULD
be taken as a request to clear any existing value of that field.
{ operation REQUIRED, MUST have the value "client_update"
client_id: "5UO9XcL4TQTa",
client_secret: "WdRKN3zeTc20"
}
5.3. Error Response access_token REQUIRED, unless presented in the Authorization Header
as in OAuth2 Bearer [OAuth.Bearer]. The Registration Access Token
that was issued during the client_associate step, or previous
client_update or rotate_secret calls.
If the request for registration is invalid or unauthorized, the redirect_uris
authorization server constructs the response by adding the following REQUIRED
parameters to the entity body of the HTTP response with a 400 status
code (Bad Request) using the "application/json" media type:
o "error" (REQUIRED). client_name RECOMMENDED
o "error_description" (OPTIONAL). Human-readable text providing client_url
additional information, used to assist in the understanding and RECOMMENDED
resolution of the error occurred.
o "error_uri" (OPTIONAL). A URI identifying a human-readable web logo_url OPTIONAL
page with information about the error, used to provide the end-
user with additional information about the error.
An example error response (with line breaks for readability): contacts OPTIONAL
HTTP/1.1 400 Bad Request tos_url OPTIONAL
Content-Type: application/json token_endpoint_auth_method OPTIONAL
Cache-Control: no-store
{ policy_url OPTIONAL
"error": "unauthorized_client",
"description": "This client is not on the
white list of this Authorization Server."
}
6. Client Registration with Pushed URL and Pulled Metadata jwk_url OPTIONAL
This registration flow works as follows: jwk_encryption_url OPTIONAL
1. The client sends its metadata URI to the client registration x509_url OPTIONAL
endpoint. The client MAY sign the metadata as a JSON Token
issuer, using the mechanisms defined in [OAuth-Sig].
2. The authorization server verifies the signature as necessary, and x509_encryption_url OPTIONAL
uses the [RFC5785] and [hostmeta] discovery mechanisms on this
URI to retrieve the host-meta document describing the client.
The host-meta document MUST contain the client name, description,
and redirection URI, and MAY contain a URI for the client icon.
+--------+ +---------------+ require_signed_request_object OPTIONAL
| Client |--(A)--- Registration Request --->| Authorization |
| | with URL | Server |
| | | |
| |<-(B)--- Client Discovery --------| |
| | | |
| |--(C)---- Host-Meta Document ---->| |
| | | |
| |<-(D)--- Registration Response ---| |
| | with Client ID Info | |
+--------+ +---------------+
Figure 2: Client Registration Flow with Pushed URL and Pulled default_max_age OPTIONAL
Metadata
6.1. Client Registration Request default_acr OPTIONAL
The client sends a JSON formatted document to the client registration For example, a client could send the following registration request
endpoint. The client includes the following parameters in the to the Client Registration Endpoint:
request:
type Following is a non-normative example request (with line wraps for
REQUIRED. This parameter must be set to "pull". display purposes only):
POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
client_url operation=client_update
REQUIRED. This field contains the URL of the homepage of the &redirect_uris=https://client.example.org/callback
client. %20https://client.example.org/callback2
&client_name=My%20Example%20
&logo_url=https://client.example.org/logo.png
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
The client MUST NOT include other metadata parameters, such as those 2.4. Client Update Response
defined in the pushed-metadata scenario.
For example, the client might send the following request: Upon successful update, the Client Registration Endpoint returns a
JSON document with the following fields as top-level members of the
root JSON object.
POST /register HTTP/1.1 client_id REQUIRED. The unique Client identifier, MUST NOT be
Host: server.example.com currently valid for any other registered Client.
Content-Type: application/json
{ Following is a non-normative example response:
type: "pull", HTTP/1.1 200 OK
url: "http://onlinephotogallery.com" Content-Type: application/json
} Cache-Control: no-store
The parameters are included in the entity body of the HTTP request {
using the "application/json" media type as defined by [JSON]. The "client_id":"s6BhdRkqt3",
parameters are serialized into a JSON structure by adding each }
parameter at the highest structure level. Parameter names and string
values are included as JSON strings.
6.2. Client Discovery [[ Editor's note: should this return the entire client data object,
for confirmation and review, including any fields that may have been
asserted by the AS? ]]
The authorization server evaluates this request and MAY perform a 2.5. Rotate Secret Request
[RFC5785] and [hostmeta] discovery mechanism on the provided URL to
the host-meta document for the client.
6.3. Client Registration Response This operation allows the client to rotate its current Client Secret,
if it has one. If the client has not been issued a Client Secret,
this operation is an error. [[ Editor's note: could this request be
used to rotate the Registration Access Token, even when there's not a
client_secret? Should something else be used to rotate the token
independently? This is an open issue. ]]
After receiving and verifying information retrieved from the client, operation REQUIRED. MUST have the value rotate_secret
the authorization server issues the client identifier and an optional
client secret, and constructs the response by adding the following
parameters to the entity body of the HTTP response with a 200 status
code (OK):
o "client_id" (REQUIRED) access_token REQUIRED. The Registration Access Token that was
issued during the client_associate step, or previous client_update
or rotate_secret calls.
o "client_secret" (OPTIONAL) Following is a non-normative example request (with line wraps for
display purposes only):
POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
The parameters are included in the entity body of the HTTP response operation=rotate_secret
using the "application/json" media type as defined by [JSON]. The
parameters are serialized into a JSON structure by adding each
parameter at the highest structure level. Parameter names and string
values are included as JSON strings.
The authorization server MUST include the HTTP "Cache-Control" 2.6. Rotate Secret Response
response header field with a value of "no-store" in any response
containing the "client_secret".
For example the authorization server might return the following Upon successful rotation of the client secret, the Client
response: Registration Endpoint returns a JSON document with the following
fields as top-level members of the root JSON object.
HTTP/1.1 200 OK client_id REQUIRED. The unique Client identifier, MUST NOT be
Content-Type: application/json currently valid for any other registered Client.
Cache-Control: no-store
{ client_secret REQUIRED. The Client secret. This MUST be unique for
"client_id":"5UO9XcL4TQTa", each "client_id".
"client_secret":"WdRKN3zeTc20"
}
6.4. Error Response registration_access_token REQUIRED The Access token to be used by
the client to perform subsequent "client_update" and
"rotate_secret" requests.
If the request for registration is invalid or unauthorized, the issued_at
authorization server constructs the response by adding the following OPTIONAL. Specifies the timestamp when the identifier was issued.
parameters to the entity body of the HTTP response with a 400 status The timestamp value MUST be a positive integer. The value is
code (Bad Request) using the "application/json" media type: expressed in the number of seconds since January 1, 1970 00:00:00
GMT.
o "error" (REQUIRED). A single error code. expires_at OPTIONAL. The number of seconds from 1970-01-01T0:0:0Z
as measured in UTC that the "client_secret" will expire or "0" if
they do not expire. See RFC 3339 [RFC3339] for details regarding
date/times in general and UTC in particular.
o "error_description" (OPTIONAL). Human-readable text providing Following is a non-normative example response:
additional information, used to assist in the understanding and HTTP/1.1 200 OK
resolution of the error occurred. Content-Type: application/json
Cache-Control: no-store
o "error_uri" (OPTIONAL). A URI identifying a human-readable web {
page with information about the error, used to provide the end- "client_id":"s6BhdRkqt3",
user with additional information about the error. "client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"registration_access_token": "this.is.a.access.token.value.ffx83",
"expires_at":2893276800
}
An example error response (with line breaks for readability): 2.7. Client Registration Error Response
HTTP/1.1 400 Bad Request When an OAuth error condition occurs, the Client Registration
Content-Type: application/json Endpoint returns an Error Response as defined in Section 5.2 of the
Cache-Control: no-store OAuth 2.0 specification.
{ When a registration error condition occurs, the Client Registration
"error": "unauthorized_client", Endpoint returns a HTTP 400 status code including a JSON object
"description": "This client is not on the describing the error in the response body.
white list of this Authorization Server."
}
If the host-meta discovery was not successful, the authorization The JSON object contains two members:
server MUST use the error code "hostmeta_error".
An example error response (with line breaks for readability): error The error code, a single ASCII string.
HTTP/1.1 404 Not Found error_description The additional text description of the error for
Content-Type: application/json debugging.
Cache-Control: no-store
{ This specification defines the following error codes:
"error": "hostmeta_error",
"description": "The hostmeta document could
not be retrieved from the URL."
}
7. Native Application Client Registration invalid_operation The value of "operation" is invalid or not
supported.
For a native application serving as an UMA host, we anticipate that invalid_redirect_uri The value of one or more "redirect_uris" is
the need for dynamic client registration to introduce this app to an invalid.
UMA authorization manager may typically happen only once (or very
infrequently), likely to a single authorization manager, and
registration could usefully take place at the time the app is
provisioned onto a device. By contrast, for a native app serving as
an UMA requester, it may need to register at multiple authorization
managers over time when seeking access tokens, at moments much later
than the original provisioning of the app onto the device.
When a native application is provisioned on a device, such as through invalid_client_metadata The value of one of the client metadata
an app store model, often it has an associated "home base" web server (Section 3) fields is invalid.
application component with which it registers (outside of any UMA-
related or OAuth-related interactions). This pairwise relationship
can be exploited in a number of ways to allow trustable, unique
metadata to be conveyed to an OAuth server and for this instance of
the app to receive a client identifier and optional secret. We have
discussed "device-initiated" and "home base-initiated" pattern
options for OAuth dynamic client registration in these circumstances.
Device-initiated flows seem more generically applicable (for example,
for both UMA host and UMA requester needs). However, a home base-
initiated flow may be preferable in case it is necessary to pre-
determine a trust level towards an OAuth server. In this case, the
home base server could initiate the registration process if and only
if there exists a trust relationship between the two parties.
Following is one option for a device-initiated flow: Following is a non-normative example of an error response:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
1. User provisions native app on device and registers with and {
authenticates to app's home-base web application. "error":"invalid_operation",
"error_description":"The value of the operation parameter must be one of client_associate, rotate_secret or client_update."
}
2. Home base provisions native app with home base-signed metadata. 3. Client Metadata
3. Whenever user tries to use native app to access a protected Clients generally have an array of metadata associated with their
resource, native app provides home base-provided metadata to unique Client Identifier at the Authorization Server. These can
server. range from human-facing display strings, such as a client name, to
items that impact the security of the protocol,
4. Server verifies home base signature by pulling public key from Extensions and profiles of this specification MAY expand this list,
home base URL and generates client identifier and secret for but MUST at least accept all parameters on this list. The
native app. Authorization Server MUST ignore any additional parameters sent by
the Client that it does not understand.
5. Server returns client identifier and secret to native app. redirect_uris
REQUIRED A space-delimited list of redirect URIs.
8. Security Considerations client_name RECOMMENDED. Human-readable name of the Client to be
presented to the user.
Following are some security considerations: client_url
RECOMMENDED. This field contains the URL of the homepage of the
client.
logo_url OPTIONAL. A URL that references a logo for the Client
application. If present, the server SHOULD display this image to
the end user during approval.
contacts OPTIONAL. Space delimited list of email addresses for
people allowed to administer the information for this Client.
This is used by some providers to enable a web UI to modify the
Client information.
tos_url OPTIONAL. URL that points to a human-readable Terms of
Service for the Client. The Authorization Server SHOULD display
this URL to the End-User if it is given.
token_endpoint_auth_method OPTIONAL. The requested authentication
type for the Token Endpoint. The options are
"client_secret_post", "client_secret_basic", "client_secret_jwt",
and "private_key_jwt". Other Authentication methods may be
defined by extension. If unspecified or omitted, the default is
"client_secret_basic" HTTP Basic Authentication Scheme as
specified in Section 2.3.1 of OAuth 2.0 [OAuth2.0]. [[ this list
of terms needs to be expanded and fully defined, especially in
reference to signed-jwt client authentication ]]
policy_url OPTIONAL. A URL location that the Client provides to the
End-User to read about the how the profile data will be used. The
Authorization Server SHOULD display this URL to the End-User if it
is given.
jwk_url OPTIONAL. URL for the Client's JSON Web Key [JWK] document
that is used for signing Token Endpoint Requests. If
jwk_encryption_url is not provided, the key at jwk_url is also
used as the key to encrypt responses to the Client. If the Client
registers both "x509_url" and "jwk_url", the keys contained in
both formats MUST be the same.
jwk_encryption_url OPTIONAL. URL for the Client's JSON Web Key
[JWK] that is used to encrypt any responses to the Client. If the
Client registers both "jwk_encryption_url" and
"x509_encryption_url", the keys contained in both formats MUST be
the same.
x509_url OPTIONAL. URL for the Client's PEM encoded X.509
Certificate or Certificate chain that is used for signing Token
Endpoint Requests. If "x509_encryption_url" is not provided,
"x509_url" it is also used to encrypt responses to the Client. If
the Client registers both "x509_url" and "jwk_url", the keys
contained in both formats MUST be the same.
x509_encryption_url OPTIONAL. URL for the Client's PEM encoded
X.509 Certificate or Certificate chain that is used to encrypt the
ID Token and User Info Endpoint Responses to the Client. If the
Client registers both "jwk_encryption_url" and
"x509_encryption_url", the keys contained in both formats SHOULD
be the same.
require_signed_request_object OPTIONAL. The JWS [JWS] "alg"
algorithm [JWA] that MUST be required by the Authorization Server.
The valid values are listed in Section 3.1 of JWA [JWA]. Servers
SHOULD support "RS256".
default_max_age OPTIONAL. (default max authentication age): Type:
Integer - Specifies that the End-User must be actively
authenticated if any present authentication is older than the
specified number of seconds. (The "max_age" request parameter
corresponds to the OpenID 2.0 PAPE "max_auth_age" request
parameter.) The "max_age" claim in the request object overrides
this default value.
default_acr OPTIONAL. (default authentication context class
reference): Type: String - Specifies the default value that the
Authorization server must use for processing requests from this
client. The "acrs_supported" element of discovery contains a list
of the supported "acr" values for this server. The "acr" claim in
the request object overrides this default value.
4. IANA Considerations
This document makes no requests of IANA.
5. Security Considerations
[[ Editor's note: Following are some security considerations taken
whole from the UMA and OpenID Connect source drafts. ]]
o No client authentication: The server should treat unsigned pushed o No client authentication: The server should treat unsigned pushed
client metadata as self-asserted. client metadata as self-asserted.
o Weak client authentication: The server should treat unsigned o Weak client authentication: The server should treat unsigned
pulled client metadata as self-asserted unless the the domain of pulled client metadata as self-asserted unless the domain of the
the client matches the client metadata URL and the URL is well- client matches the client metadata URL and the URL is well-known
known and trusted. and trusted.
o Strong client authentication: The server should treat signed o Strong client authentication: The server should treat signed
client metadata (pushed or pulled) and a signed metadata URL as client metadata (pushed or pulled) and a signed metadata URL as
self-asserted unless it can verify the signature as being from a self-asserted unless it can verify the signature as being from a
trusted source. trusted source.
9. Acknowledgments Since requests to the Client Registration Endpoint result in the
transmission of clear-text credentials (in the HTTP request and
response), the server MUST require the use of a transport-layer
security mechanism when sending requests to the Registration
Endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or
TLS 1.0 [RFC2246] and MAY support additional transport-layer
mechanisms meeting its security requirements. When using TLS, the
Client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125].
The authors thank the User-Managed Access Work Group participants, Requests to the Registration Endpoint for "client_update" MUST have
particularly the following, for their input to this document: some rate limiting on failures to prevent the Client secret from
being disclosed though repeated access attempts.
o Domenico Catalano A rogue RP might use the logo for the legitimate RP, which it is
trying to impersonate. An IdP needs to take steps to mitigate this
phishing risk, since the logo could confuse users into thinking
they're logging in to the legitimate RP. An IdP could also warn if
the domain/site of the logo doesn't match the domain/site of redirect
URIs. An IdP can also make warnings against untrusted RPs in all
cases, especially if they're dynamically registered, have not been
trusted by any users at the IdP before, and want to use the logo
feature.
o George Fletcher In a situation where the Authorization Server is supporting open
Client registration, it must be extremely careful with any URL
provided by the Client that will be displayed to the user (e.g.
"logo_url" and "policy_url"). A rogue Client could specify a
registration request with a reference to a drive-by download in the
"policy_url". The Authorization Server should check to see if the
"logo_url" and "policy_url" have the same host as the hosts defined
in the array of "redirect_uris".
o Nat Sakimura 6. Acknowledgments
10. Document History The authors thank the User-Managed Access Work Group and the OpenID
Connect Working Group participants for their input to this document.
7. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
11. References - 01
o Merged UMA and OpenID Connect registrations into a single document
11.1. Normative References o Changed to form-paramter inputs to endpoint
o Removed pull-based registration
- 00
o Imported original UMA draft specification
8. References
8.1. Normative References
[JSON] Crockford, D., "The application/json Media Type for [JSON] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", 2006, JavaScript Object Notation (JSON)", 2006,
<http://tools.ietf.org/html/rfc4627>. <http://tools.ietf.org/html/rfc4627>.
[JWA] Jones, M., "JSON Web Algorithms", May 2012.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", May 2012.
[JWK] Jones, M., "JSON Web Key (JWK)", May 2012.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature", May 2012.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token",
May 2012.
[OAuth-Sig] [OAuth-Sig]
Balfanz, D., "OAuth Signature proposals", 2010, <http:// Balfanz, D., "OAuth Signature proposals", 2010, <http://
www.ietf.org/mail-archive/web/oauth/current/ www.ietf.org/mail-archive/web/oauth/current/
msg03893.html>. msg03893.html>.
[OAuth.Bearer]
Jones, M. and D. Hardt, "OAuth 2.0 Protocol: Bearer
Tokens", Aug 2012.
[OAuth2.0]
Hardt, D., "OAuth 2.0 Authorization Protocol", July 2012.
[OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0",
May 2012.
[OpenID.Session]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
N. Agarwal, "OpenID Connect Session Management 1.0",
August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010. April 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009.
[hostmeta] [hostmeta]
Hammer-Lahav, E., "Web Host Metadata", 2010, <http:// Hammer-Lahav, E., "Web Host Metadata", 2010, <http://
xml.resource.org/public/rfc/bibxml3/ xml.resource.org/public/rfc/bibxml3/
reference.I-D.draft-hammer-hostmeta-13.xml>. reference.I-D.draft-hammer-hostmeta-13.xml>.
11.2. Non-Normative References 8.2. Non-Normative References
[UMA-Core] [UMA-Core]
Scholz, C., "UMA Requirements", 2010, <http:// Scholz, C., "UMA Requirements", 2010, <http://
tools.ietf.org/id/draft-hardjono-oauth-umacore-04.txt>. tools.ietf.org/id/draft-hardjono-oauth-umacore-04.txt>.
[UMA-Reqs] [UMA-Reqs]
Maler, E., "UMA Requirements", 2010, <http:// Maler, E., "UMA Requirements", 2010, <http://
kantarainitiative.org/confluence/display/uma/ kantarainitiative.org/confluence/display/uma/
UMA+Requirements>. UMA+Requirements>.
[UMA-UC] Akram, H., "UMA Explained", 2010, <http:// [UMA-UC] Akram, H., "UMA Explained", 2010, <http://
kantarainitiative.org/confluence/display/uma/ kantarainitiative.org/confluence/display/uma/
UMA+Scenarios+and+Use+Cases>. UMA+Scenarios+and+Use+Cases>.
Authors' Addresses Authors' Addresses
Thomas Hardjono (editor) Justin Richer (editor)
The MITRE Corporation
Phone:
Fax:
Email: jricher@mitre.org
URI:
Thomas Hardjono
MIT MIT
Phone: Phone:
Fax: Fax:
Email: hardjono@mit.edu Email: hardjono@mit.edu
URI: URI:
Maciej Machulak Maciej Machulak
Newcastle University Newcastle University
skipping to change at line 810 skipping to change at page 20, line 11
Email: eve@xmlgrrl.com Email: eve@xmlgrrl.com
URI: http://www.xmlgrrl.com URI: http://www.xmlgrrl.com
Christian Scholz Christian Scholz
COM.lounge GmbH COM.lounge GmbH
Phone: Phone:
Fax: Fax:
Email: Email:
URI: URI:
Nat Sakimura
Nomura Research Institute, Ltd.
Email: n-sakimura@nri.co.jp
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
 End of changes. 142 change blocks. 
513 lines changed or deleted 571 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/