One document matched: draft-wmills-oauth-lrdd-01.txt
Differences from draft-wmills-oauth-lrdd-00.txt
Individual W. Mills
Internet-Draft Yahoo! Inc.
Intended status: Informational June 14, 2012
Expires: December 16, 2012
Link Type Registry for OAuth 2
draft-wmills-oauth-lrdd-01.txt
Abstract
Defines link type registrations for the OAuth 2 authentication
framework.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Mills Expires December 16, 2012 [Page 1]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Link Type Registration . . . . . . . . . . . . . . . . . . 6
4.1.1. OAuth 2 Authorization Endpoint . . . . . . . . . . . . 6
4.1.2. OAuth 2 Token Endpoint . . . . . . . . . . . . . . . . 6
4.1.3. OAuth 1.0a Request Initiation Endpoint . . . . . . . . 7
4.1.4. OAuth 1.0a Authorization Endpoint . . . . . . . . . . 7
4.1.5. OAuth 1.0a Token Endpoint . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Document History . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Mills Expires December 16, 2012 [Page 2]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
1. Introduction
This document defines the link type [RFC5988] registrations for the
OAuth 2 [I-D.ietf-oauth-v2] authentication framework. It also
defines link type registrations for OAuth 1.0a [RFC5849]. These link
types are used during the endpoint discovery process using Web Host
Metadata [RFC6415] and Webfinger [I-D.jones-appsawg-webfinger] by
clients needing to discover the authorization, token, and initiation
endpoints for a service or site.
Mills Expires December 16, 2012 [Page 3]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
2. Terminology
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 [RFC2119].
The reader is assumed to be familiar with the terms used in the OAuth
2.0 specification [I-D.ietf-oauth-v2].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. Line breaks have been inserted for readability.
Note that the IMAP SASL specification requires base64 encoding
message, not this memo.
Mills Expires December 16, 2012 [Page 4]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
3. Security Considerations
This document is informational, defining values in existing
registries, and as such has no security properties to discuss.
Mills Expires December 16, 2012 [Page 5]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
4. IANA Considerations
4.1. Link Type Registration
Pursuant to [RFC5988] The following link type registrations [[will
be]] registered by mail to link-relations@ietf.org.
4.1.1. OAuth 2 Authorization Endpoint
o Relation Name: oauth2-authorize
o Description: An OAuth 2.0 authorization endpoint.
o Reference: [I-D.ietf-oauth-v2]
o Notes: This link type indicates an OAuth 2.0 authorization
endpoint that can be used for user authentication/authorization
for the endpoint providing the link.
o Application Data: [optional]
4.1.2. OAuth 2 Token Endpoint
o Relation Name: oauth2-token
o Description: The OAuth token endpoint used to get tokens for
access.
o Reference: [I-D.ietf-oauth-v2]
o Notes: The OAuth 2.0 token endpoint to be used for obtaining
tokens to access the endpoint providing the link.
o Application Data: This link type has two link-extensions:
grant-types: A space separated list of OAuth 2.0 grant types (see
section 4 of [I-D.ietf-oauth-v2]) that can be used at the token
endpoint to obtain a token. This is not an exclusive list, it
provides a hint to the application of what SHOULD be valid. A
token endpoint MAY support additional grant types not
advertised by a discovery service. The client MAY use this to
determine if the client supports the grant types avaiable.
token-types: A space separated list of OAuth 2.0 token types (see
section 7.1 of [I-D.ietf-oauth-v2]) that may be issued by the
token endpoint. It is possible for an token endpoint to issue
multiple tokens, and types may vary based on scope or other
factors. This is not an exclusive list, it provides a hint to
Mills Expires December 16, 2012 [Page 6]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
the application of what SHOULD be valid, and it MAY be used by
a client to determine if the client supports the token type(s)
available.
4.1.3. OAuth 1.0a Request Initiation Endpoint
o Relation Name: oauth-initiate
o Description: The OAuth 1.0a request initiation endpoint used to
get an access request.
o Reference: [RFC5849]
o Notes: The OAuth 1.0a endpoint used to initiate the sequence, this
temporary request is what the user approves to grant access to the
resource.
o Application Data:
4.1.4. OAuth 1.0a Authorization Endpoint
o Relation Name: oauth-authorize
o Description: The OAuth 1.0a authorization endpoint used to approve
an access request.
o Reference: [RFC5849]
o Notes:
o Application Data:
4.1.5. OAuth 1.0a Token Endpoint
o Relation Name: oauth-token
o Description: The OAuth 1.0a token endpoint used to exchange an
approved access request for a token.
o Reference: [RFC5849]
o Notes:
o Application Data:
Mills Expires December 16, 2012 [Page 7]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
5. Examples
Below we have an example of a server advertizing the OAuth 2
endpoints as a result of a query against "acct:carol@example.com".
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=UTF-8
{
"subject" : "acct:carol@example.com",
"links" :
[
{
"rel" : "oauth2-athorize",
"href" : "http://login.example.com/oauth2/authorize"
},
{
"rel" : "oauth2-token",
"href" : "https://login.example.com/oauth2/token"
"grant-types" : "code password"
"token-types" : "bearer"
}
]
}
Figure 1: Example of a WebFinger type query result
In the case of a failed authorizationto access an HTTP based service,
the example below shows an extremely minimal HTTP response. (Long
lines wrapped for readability.)
HTTP/1.1 401 Unauthorized
WWW-Authenticate: BEARER realm="example.com"
Link: <https://login.example.com/oauth> rel="oauth2-authorize"
Link: <https://login.example.com/oauth> rel="oauth2-token"
grant-types="code password" token-types="bearer"
Figure 2: Example of LINK headers as a result of a failed HTTP
authorization
Mills Expires December 16, 2012 [Page 8]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
6. References
6.1. Normative References
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Framework", draft-ietf-oauth-v2-27 (work
in progress), June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
6.2. Informative References
[I-D.jones-appsawg-webfinger]
Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
draft-jones-appsawg-webfinger-05 (work in progress),
May 2012.
[RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata",
RFC 6415, October 2011.
Mills Expires December 16, 2012 [Page 9]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
Appendix A. Document History
[[ to be removed by RFC editor before publication as an RFC ]]
-01
o Editorial changes, corrected authenticatre to authrorize is most
places, and added examples.
-00
o Initial revision
Mills Expires December 16, 2012 [Page 10]
Internet-Draft A SASL/GSS-API Mechanism for OAuth June 2012
Author's Address
William Mills
Yahoo! Inc.
Phone:
Email: wmills_92105@yahoo.com
Mills Expires December 16, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 15:03:59 |