One document matched: draft-hunt-oauth-client-association-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-hunt-oauth-client-association-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc tocdepth='3' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc compact='no' ?>
<?rfc subcompact='no' ?>
<?rfc strict='yes' ?>
<?rfc notedraftinprogress='yes' ?>
<front>
<title abbrev="OAuth-Client-Association-00">OAuth Client
Association</title>
<author fullname="Phil Hunt" initials="P" role="editor" surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<author fullname="Tony Nadalin" initials="T." surname="Nadalin">
<organization>Microsoft</organization>
<address>
<email>tonynad@microsoft.com</email>
</address>
</author>
<date day="18" month="September" year="2013"/>
<area>Security</area>
<workgroup>OAuth</workgroup>
<abstract>
<t>This specification defines methods that OAuth clients may use to
associate (register) with service providers for the purposes of
accessing OAuth protected resources. The document describes different
classifications of OAuth clients and the process to directly access or
associate for access with a particular OAuth Framework protected service
provider.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The OAuth 2.0 Authorization Framework <xref target="RFC6749"/> is a
framework by which client applications use access tokens issued by
authorization servers to access to a service provider's software API
endpoints. As a framework, OAuth 2.0 enables many different flows by
which a client application may obtain an access token including
delegated authorization from a user.</t>
<t>The OAuth Authorization Framework defines only two types of clients:
public and confidential. Public clients have client_id's issued once
where each instance shares the same client_id and are usually native
applications. Confidential clients typically have a unique client_id per
instance and typically deployed in secure environments on web
application platforms. In both cases, OAuth has limited support for
building applications that are intended to work with multiple
deployments that are not known at compilation or software packaging
time.</t>
<t>This specification defines a taxonomy of clients, and the methods by
which a client instance may either register with, or directly request
tokens from, an OAuth endpoint. The generic term for how client
instances work with a new OAuth endpoint is "association". This
specification defines 3 types of association:<list hangIndent="10"
style="hanging">
<t hangText="Static">Are clients that are built to work with one or
more endpoint(s) that are known at the time the client applicaiton
is built. A <spanx style="verb">client_id</spanx> and any associated
credentials are typically issued to the developer. Multiple
instances of the same client share the same client_id. The
determination for "public" vs. "confidential" client is as per
Section 2.1 <xref target="RFC6749"/>.</t>
<t hangText="Dynamic">Are clients that associate with one or more
endpoints triggered by application based workflows, configuration or
installation events. Associations may be temporary or be extended
over a long period of time. A <spanx style="verb">client_id</spanx>
is issued at association time along with a token based client
credential and an optional client referesh token that enables
registration updates and client token rotation. Clients that
associate dynamically and are issued individual <spanx style="verb">client_id</spanx>
are considered "confidential" as defined in Section 2.1 <xref
target="RFC6749"/>.</t>
<t hangText="Transient">Are clients that associate with one or more
endpoints triggered by application based events or workflows. These
clients typically use the OAuth "Implicit" grant per Section 4.2 of
<xref target="RFC6749"/> and as such do not require an instance
specific <spanx style="verb">client_id</spanx> or a client
credential. These associations typically exist for the life of an
access token and may only last for seconds or minutes. These clients
use a client asserted client_id and are considered public as defined
in Section 2.1 <xref target="RFC6749"/>.</t>
</list></t>
<t>This draft defines how software statements <xref
target="I-D.draft-hunt-oauth-software-statement"/> can be used to
associate dynamic and transient clients with OAuth protected service
providers.</t>
<section anchor="Notation" title="Notational Conventions">
<t>The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>Unless otherwise noted, all the protocol parameter names and values
are case sensitive.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>This specification uses the terms "Access Token", "Refresh Token",
"Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Public Client", "Confidential
Client", "Client Identifier", "Client Secret", "Protected Resource",
"Resource Owner", "Resource Server", and "Token Endpoint" defined by
<xref target="RFC6749">OAuth 2.0</xref>.</t>
<t>This specification uses the terms "Deployment Organization",
"Software API Deployment", "Software API Publisher", "Client
Developer", and "Software Statement" as defined in <xref
target="I-D.draft-hunt-oauth-software-statement"/>.</t>
<t>This specification defines the following additional terms:<list
hangIndent="4" style="hanging">
<t hangText="Client Resource Endpoint">An optional OAuth 2.0
protected resource endpoint through which registration information
for a registered client can be accessed and optionally managed.
The API definition is out of scope of this specification.</t>
<t hangText="Initial Access Token">An OAuth 2.0 access token is
typically issued by a software API deployment's security domain
and used by a dynamic client a to associate a client for use with
a particular software API deployment. The token is usually issued
by the same security domain as the Service API the client is
registering for. The content, structure, generation, and
validation of this token are out of scope for this
specification.</t>
<t hangText="Client Refresh Credential">A client refresh token is
an optional credential token a client may use for the purpose of
supporting server or client initiated rotation of client
credentials. If client credentials are revoked or expired, the
registered client may use the client refresh token to refresh its
registration and obtain new client credentials.</t>
</list></t>
</section>
</section>
<section anchor="lifecycle" title="Client Association Lifecycle">
<t>This specification defines an association lifecycle that registers a
client for one target resource API per "association". Clients that need
to register for more than one resource API should typically make a
separate registration request for each API being registered.</t>
<t>The abstract association flow illustrated in Figure 1 describes the
relationship and interaction between a software API publisher, a client
developer, a deployed client software instance and the software API
deployment registration services in this specification. This figure does
not demonstrate error conditions.</t>
<t><figure align="center" anchor="abstractFlow" title="Client Lifecycle">
<artwork height="46"> Client App
Developer
O (A) Obtain Software Statement ****************
\|/ <-------------------------------------- * Software API *
| * Publisher *
/ \ ****************
|
| |
| |
|D S | A
|i o | p
|s f | p
|t t | r (B)
A |r w | o
p |i a | v
p |b r | a
|u e | l
|t |
|i |
|o |
|n *************|********
v * v *
+------------+ * +---------------+ *
| Client App | (C) Client Association & Authz * | OAuth 2.0 | *
| Instance | --------------------------------->| Authorization | *
+------------+ * | Server | *
* +---------------+ *
* OAuth 2.0 aware *
* Service Provider *
**********************
Legend:
O
\|/ - Developer
|
/ \
+----+
| | - Piece of software
| |
+----+
******
* * - Organization
* *
******</artwork>
</figure></t>
<t><list hangIndent="4" style="hanging">
<t hangText="(A)">The client developer packages the client software
with the signed software statement and distributes the client
application. Local distributions may also be produced that include
an initial registration token designed for use within a specific
deployment domain. The method for doing this is out-of-scope of this
specification.</t>
<t hangText="(B)">Upon receiving, or becoming aware of, a client
application software distribution, an administrator configures
administrative policy to accept or reject a particular client
software statement within a deploying organization. Additionally an
administrator may configure broader policy that accepts software by
name, author, or signing organization. An administrator might also
pre-approve client software by automatically accepting software
statements from a particular signer or other category that can be
derived from a software statement. As part of the approval, an
initial registration token may be generated for use with a local
distribution of the client software (step A).</t>
<t hangText="(C)">To associate with a new OAuth provider, dynamic
clients present a software statement, deployment specific
parameters, and an optional initial registration token with a <spanx
style="verb">grant_type</spanx> of <spanx style="verb">urn:ietf:params:oauth:grant-type:client-assoc</spanx>.
The authorization server MAY provide a client resource endpoint URL
that Clients MAY use to access or update their registration. Clients
wishing to rotate client credentials follow the same process except
they use the client refresh token as their registration token.</t>
<t>Transient clients MAY perform implicit authorization requests
(per section 4.2 of <xref target="RFC6749"/>) by submitting their
software statement as the client identifier (<spanx style="verb">client_id</spanx>).
Upon receiving an access token, transient client MAY then make
normal resource requests.</t>
</list></t>
</section>
<section anchor="association" title="Client Association">
<t>This section defines 3 types of client association and the process by
which each client type associates with a software API deployment.</t>
<section title="Static Association Clients">
<t>Clients that are written for a specific set of endpoints and do not
require installation or runtime association are known as 'static
clients'. These clients typically have a <spanx style="verb">client_id</spanx>(s)
and client credential(s) acceptable to the deployment endpoint(s) that
are integrated with the application at compilation or packaging time.
The process for how this is performed is out of scope of this
specification. These clients SHOULD work using the normal OAuth2
Framework calls <xref target="RFC6749"/>.</t>
</section>
<section title="Dynamic Association Clients">
<t>Dynamic association defines 3 types of transactions to support the
life-cycle of clients that associate on-the-fly with deployment
endpoints.<list style="symbols">
<t>The first time a client associates, it presents its software
statement, and any optional registration parameters, to the token
endpoint and receives a client credential token, an optional
client refresh token, and an optional client association resource
endpoint URL. Clients MAY also present an initial access token in
the authoirzation header as an indication of prior authorization
with the authorization server.</t>
<t>A client MAY update its association after a configuration
change, software update, or expiration or revocation of its client
credential, MAY present its client refresh token as its
authorization plus the client's software statement and optional
configuration parameters to receive a new client credentaial token
and an optional client refresh token.</t>
</list></t>
<t>Dynamic clients association clients use the OAuth token endpoint
with <spanx style="verb">grant_type</spanx> of <spanx style="verb">urn:ietf:params:oauth:grant-type:client-assoc</spanx>
to submit a software statement and any per instance registration
parameters. In response the registration endpoint confirms the
registration by issuing a client token and an optional client refresh
token. Additionally, the registration endpoint MAY provide a client
resource endpoint which can be used to retrieve additional information
about the client. The use and function of the client resource endpoint
is out of scope of this specification.</t>
<t/>
<section title="Registration Request">
<t>The value of <spanx style="verb">grant_type</spanx> MUST be
<spanx style="verb">urn:ietf:params:oauth:grant-type:client-assoc</spanx>.</t>
<t>The value of the <spanx style="verb">assertion</spanx> parameter
MUST contain a software statement <xref
target="I-D.draft-hunt-oauth-software-statement"/>.</t>
<t>The authorization header MAY be ONE OF three values:<list
style="symbols">
<t>Omitted to indicate a new association.</t>
<t>An initial access token to indicate a new assocation that has
been pre-authorized.</t>
<t>A client refresh token to update an existing association and
to rotate the client access token and optional client refresh
token.</t>
</list></t>
<t>A non-normative, JSON encoded example of a new association
request is as follows:<figure align="center">
<artwork>POST /token.oauth2 HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: as.example.com
{
"grant_type"=
"urn:ietf:params:oauth:grant-type:client-assoc"
"redirect_uris":[
"https://client.example.org/callback",
"https://client.example.org/callback2"
],
"software_statement":"eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]",
"extension_parameter":"foo"
}
</artwork>
</figure></t>
<t>The update association is similar to a new association. In the
update, the main difference is the client supplies the client
refresh token in the <spanx style="verb">Authorization</spanx>
header. In a software update (e.g. a new verson of the client
software), the client MAY provide an updated or revised software
statement (not shown). A non-normative, JSON encoded example of an
association update request is as follows:<figure align="center">
<artwork>POST /token.oauth2 HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: as.example.com
{
"grant_type"=
"urn:ietf:params:oauth:grant-type:client-assoc"
"redirect_uris":[
"https://client.example.org/callback",
"https://client.example.org/callback2"
],
"software_statement":"eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]",
"extension_parameter":"foo"
}
</artwork>
</figure></t>
<t>The client MAY include additional instance specific parameters
defined in <xref
target="I-D.draft-hunt-oauth-software-statement">Section 2.2
</xref>. If a <spanx style="verb">software_statement</spanx> is
enclosed, the token server MUST ignore any attribute in the JSON
request that is specified in the statement.</t>
<t/>
</section>
<section title="Association Processing">
<t>If an initial access token or client referesh token is presented
as an authentication credential, the server MUST process the token
as per section 3.2.1 of <xref target="RFC6749"/>.</t>
<t>The received software statement MUST have be validated per
Section 2.3 of <xref
target="I-D.draft-hunt-oauth-software-statement"/></t>
<t>If the software statement includes values for <spanx
style="verb">redirect_url</spanx> and the request includes a <spanx
style="verb">redirect_url</spanx> value, the request MUST be
rejected. [[should this be a SHOULD?]]</t>
<t>Unless otherwise stated, the server SHOULD ignore any request
parameter that duplicates values provided in the software
statement.</t>
<t>For each new association, the server SHOULD generate a new <spanx
style="verb">client_id</spanx> and client token. In dynamic
associations, a single <spanx style="verb">software_id</spanx> will
have one or more <spanx style="verb">client_id</spanx> values
associated with it.</t>
<t>The server SHOULD NOT change the value of <spanx style="verb">client_id</spanx>
if the client updates the association by presenting a client refresh
token. In such a case, the <spanx style="verb">software_id</spanx>
value contained in the software statement SHOULD NOT change. When an
association is updated, the server MAY invalidate outstanding OAuth
authorizations and access tokens issued to the client. [[OR, should
the server maintain authorizations and access tokens?]]</t>
</section>
<section title="Successful Association Response">
<t>After successfully processing the association request, the token
server SHALL respond with the following:<list hangIndent="8"
style="hanging">
<t hangText="client_id">REQUIRED. A unique client identifier
assigned to the client software instance.</t>
<t hangText="token_type">REQUIRED. The type of token issued by
the authorization server in parameter client_token for the
purpose of client authentication as described in <xref
target="RFC6749">Section 7.1</xref>.</t>
<t hangText="client_token">REQUIRED. The client credential token
issued by the authorization server. The type and usage is
indicated by the parameter token_type.</t>
<t hangText="expires_in">RECOMMENDED. The lifetime in seconds of
the access token. For example, the value "3600" denotes that the
access token will expire in one hour from the time the response
was generated. If omitted, the authorization server SHOULD
provide the expiration time via other means or document the
default value.</t>
<t hangText="refresh_token">OPTIONAL. A client refresh token of
type <spanx style="verb">bearer</spanx> which can be used to
refresh a client association. The token MAY be used to update
association via the token grant request and MAY be used to
access the client association resource endpoint indicated in
<spanx style="verb">location</spanx>.</t>
<t hangText="location">OPTIONAL. A URI specifying the location
of a resource endpoint representing the clients association with
the endpoint. The type of endpoint and usage is out of scope of
this specification. [[should there be a location type? e.g. SCIM
Dynamic Management?]</t>
</list></t>
<t>A non-normative JSON formated response (some values clipped for
readability):<figure align="center">
<artwork>HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id":"s6BhdRkqt3",
"token_type":"bearer",
"client_token":"eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]",
"client_id_issued_at":2893256800,
"expires_at":2893276800,
"refresh_token":"mF_9.B5f-4.1JqM",
"location":"https://scim.example.com/Clients/s6BhdRkqt3",
"extension_parameter": "foo"
}</artwork>
</figure></t>
<t>An non-normative HoK token example (some values clipped for
readability):<figure align="center">
<artwork>HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id":"s6BhdRkqt3",
"token_type":"hok",
"client_token":"eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]",
"secret"="somesymetrickey",
"client_id_issued_at":2893256800,
"expires_at":2893276800,
"refresh_token":"mF_9.B5f-4.1JqM",
"location":"https://scim.example.com/Clients/s6BhdRkqt3"
}</artwork>
</figure></t>
</section>
<section anchor="association-error" title="Error Responses">
<t>When an OAuth 2.0 error condition occurs, such as the client
presenting an invalid initial access token or client refresh token,
the authorization server returns an error response appropriate to
the OAuth 2.0 token type. This error response is defined in Section
3.2.1 of <xref target="RFC6750"/>.</t>
<t>When a registration error condition occurs, the authorization
server returns an HTTP 400 status code (unless otherwise specified)
with content type <spanx style="verb">application/json</spanx>
consisting of a <xref target="RFC4627">JSON object</xref> describing
the error in the response body.</t>
<t>The JSON object contains two members:</t>
<t><list style="hanging">
<t hangText="error"><vspace/>The error code, a single ASCII
string.</t>
<t hangText="error_description"><vspace/>A human-readable text
description of the error for debugging.</t>
</list></t>
<t>This specification defines the following error codes:</t>
<t><list style="hanging">
<t hangText="invalid_statement">The software statement presented
is not a valid assertion according to <xref
target="I-D.draft-hunt-oauth-software-statement"/>.</t>
<t hangText="unapproved_software">The software statement
presented IS NOT approved or IS NOT registered for use with the
current endpoint.</t>
<t hangText="invalid_redirect_uri"><vspace/>The value of one or
more <spanx style="verb">redirect_uris</spanx> is invalid.</t>
<t hangText="invalid_client_metadata"><vspace/>The value of one
of the request parameters is invalid or is in conflict with a
value in the software statement.</t>
</list></t>
<figure>
<preamble>Following is a non-normative example of an error
response (with line wraps for display purposes only):</preamble>
<artwork>HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_redirect_uri",
"error_description":"The redirect URI of http://sketchy.example.com
is not allowed for this server."
}</artwork>
</figure>
</section>
</section>
<section title="Transient Association">
<t>Transient association clients access service providers for a
limited relationship usually defined by the life of any access token
issued. These clients are characterized by having no deployment
organization issued client tokens or identifiers. Transient clients
MAY use their <spanx style="verb">software_id</spanx> as the <spanx
style="verb">client_id</spanx> and use their software statement as
their client token according to according to section 2.2 of <xref
target="I-D.ietf-oauth-jwt-bearer"/>.</t>
<t>Per section 4.2 of <xref target="RFC6749"/>, implicit flow clients
SHALL provide their <spanx style="verb">software_id</spanx> as the
<spanx style="verb">client_id</spanx> when making implicit
authorization requests.</t>
<t>Per section 2.1.2 of <xref
target="I-D.draft-hunt-oauth-software-statement"/>, it is expected
that the software_id SHOULD be known to the service provider as part
of its software approval process and is out of scope of this
specification. If the software_id is not known, the server SHOULD
respond with error code <spanx style="verb">unapproved_software</spanx>
per <xref target="association-error"/>.</t>
<t>Transient clients SHOULD be considered as 'public clients' as
defined in <xref target="RFC6749"/>.</t>
</section>
<section title="Client Disassociation">
<t>[[TBD - should this be supported?]]</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The following is a parameter registration request, as defined Section
11.2, the OAuth parameters registry, of OAuth 2.0 <xref
target="RFC6749"/>. [[NEED TO REGISTER: software_statement,
redirect_uri, etc ]]</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>[[TO BE REVISED]]</t>
<t>For clients that use redirect-based grant types such as Authorization
Code and Implicit, authorization servers SHOULD require clients to
register their <spanx style="verb">redirect_uris</spanx>if not specified
in their software statement. Requiring clients to do so can help
mitigate attacks where rogue actors inject and impersonate a validly
registered client and intercept its authorization code or tokens through
an invalid redirect URI.</t>
<t>Clients with software statements containing <spanx style="verb">redirect_uris</spanx>
MUST NOT specify a new redirect_uri during registration.</t>
<t>The authorization server MUST treat all client metadata, including
software statements, as self-asserted. A rogue client might use the name
and logo for the legitimate client, which it is trying to impersonate.
For instance, an authorization server could warn if the domain/site of
the logo doesn't match the domain/site of redirect URIs. An
authorization server can also present warning messages to end users
about untrusted clients in all cases, especially if such clients have
not been associated by the authorization server before.</t>
<t>Authorization servers MAY assume that registered client software
sharing the same software assertion, software_id, and other metadata
SHOULD have similar operational behaviour metrics. Similarly,
Authorization server administrators MAY use software_id and
software_version to facilitate normal change control and approval
management of client software including:<list style="symbols">
<t>Approval of specific clients software for use with specific
protected resources.</t>
<t>Lifecycle management and support of specific software versions as
indicated by software_version.</t>
<t>Revocation of groups of client credentials and associated access
tokens when support issues or security risks identified with a
particular client software as identified by software_id and
software_version.</t>
</list></t>
<t>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. <spanx
style="verb">logo_uri</spanx>, <spanx style="verb">tos_uri</spanx>,
<spanx style="verb">client_uri</spanx>, and <spanx style="verb">policy_uri</spanx>).
For instance, a rogue client could specify a registration request with a
reference to a drive-by download in the <spanx style="verb">policy_uri</spanx>.
The authorization server SHOULD check to see if the <spanx style="verb">logo_uri</spanx>,
<spanx style="verb">tos_uri</spanx>, <spanx style="verb">client_uri</spanx>,
and <spanx style="verb">policy_uri</spanx> have the same host and scheme
as the those defined in the array of <spanx style="verb">redirect_uris</spanx>
and that all of these resolve to valid Web pages.</t>
<t>Access tokens issued to clients to facilitate update or retrieval of
client registrations SHOULD be short lived.</t>
<t>Clients SHOULD rotate their client credentials before they expire by
obtaining an access token from the authorization server using the
registration scope. If a client has not successfully rotated its
credential prior to expiry, the client MUST register as a new
client.</t>
<t>If a client is deprovisioned from a server (due to expiry or
de-registration), any outstanding Registration Access Token for that
client MUST be invalidated at the same time. Otherwise, this can lead to
an inconsistent state wherein a client could make requests to the client
configuration endpoint where the authentication would succeed but the
action would fail because the client is no longer valid.</t>
<t>Clients that are unable to retain a client credential for the life of
the client instance MAY NOT register and should continue to be treated
as Public clients as defined by OAuth 2.0.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-assertions-12.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-jwt-bearer-06.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-jose-json-web-key-14.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-saml2-bearer-17.xml'?>
<reference anchor="IANA.Language">
<front>
<title>Language Subtag Registry</title>
<author>
<organization>Internet Assigned Numbers Authority
(IANA)</organization>
</author>
<date year="2005"/>
</front>
<format target="http://www.iana.org/assignments/language-subtag-registry"
type="TXT"/>
</reference>
<reference anchor="I-D.draft-hunt-oauth-software-statement">
<front>
<title>OAuth Software Statement</title>
<author fullname="Phil Hunt" initials="P" role="editor"
surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<author fullname="Tony Nadalin" initials="T." surname="Nadalin">
<organization>Microsoft</organization>
<address>
<email>tonynad@microsoft.com</email>
</address>
</author>
<date/>
</front>
</reference>
</references>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>This draft was based upon in large part upon the work in
draft-ietf-oauth-dyn-reg-14, draft-richer-oauth-dyn-reg-core-00 and
draft-richer-oauth-dyn-reg-12 and WG discussions. The authors would like
to thank Justin Richer and the members of the OAuth Working Group.</t>
</section>
<section anchor="History" title="Document History">
<t>[[ to be removed by the RFC editor before publication as an RFC
]]</t>
<t>-00</t>
<t><list style="symbols">
<t>First draft.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:43 |