I just finished the first version of my I-D on "multiple access tokens"
and would like to initiate a discussion whether the WG sees this as a
potential WG item.
Due to the pre-meeting cutoff date for submitting new drafts, I cannot
submit it to the IETF site now. Since I don't want to lose weeks, I
attached the document to this mail. I will upload the document to the
IETF site after 2010-07-26.
I would appreciate any feedback on the I-D.
regards,
Torsten.
Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav:
I strongly believe that it should be first presented as an I-D. This is true in
general for most proposed changes of this size. It is hard to tell how big of
an impact a change like this will have without some actual text. Once proposed,
the WG can decide if this is of interest as a WG item. If it is, we discuss the
technical details. Then, we can have a chat about editorial work and how to
best fit it within the OAuth specifications framework.
Hope this helps.
EHL
Title: Multiple access tokens
TOC
Open Authentication ProtocolT. Lodderstedt
Internet-DraftDeutsche Telekom AG
Intended status: Standards TrackJuly 10, 2010
Expires: January 11, 2011
Multiple access tokensdraft-lodderstedt-oauth-multiple-access-tokens-00
Abstract
This document proposes changes to the OAuth v2 specification
in order to support the issuance of access tokens, which are valid
for particular resource servers and the exchange of a single access
grant (end-user authorization code, credentials, assertion, refresh
token e.t.c) into multiple resource server-specific access tokens.
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 January 11, 2011.
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1.
Introduction
2.
Service-specific tokens
2.1.
Definitions
2.2.
Requesting a service-specific token
2.3.
Access token response
3.
Multiple-tokens mode
3.1.
Requesting tokens for multiple services
3.2.
Access token response
3.3.
Service usage
3.4.
Refresh token
4.
Proposed changes
4.1.
Changes to section 3.
4.2.
Changes to section 3.1.
4.3.
Changes to section 4.
4.4.
Changes to section 4.2.
4.5.
Changes to section 5.
5.
Acknowledgements
6.
IANA Considerations
7.
Security Considerations
8.
Informative References
§
Author's Address
TOC
1.
Introduction
OAuth v2
[draft‑ietf‑oauth‑v2‑09] (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol draft-ietf-oauth-v2-09,” June 2010.)
distinguishes the role of resource server and
authorization server
and that way also enables deployments where a
single authorization
server is responsible for authorizing access to
multiple, independent
resource servers.
It may be expected that more and more clients will integrate (or
mash-up) several of such services. As an example, one might imagine
a communication client integrating e-Mail via IMAP, Voice over IP
using the SIP protocol, contacts via SyncML over HTTP, and
webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV.
For a particular end-user, the client may discover that all of the
end-user's services rely on the same OAuth2-based authorization
server because they are provided by the same organization (e.g. an
isp or a telco). For reasons of simplicity and user experience, the
client may want to acquire access authorization to all services in a
single authorization flow or for a single access grant.
Another
example of multi-service clients are OpenId Connect
[openid‑connect] (Recordon, D. and E. Hammer-Lahav, Ed., “OpenId Connect,” May 2010.)
clients.
They will very likely require acc
