[Openid-specs-ab] Reminder of the call today
Breno de Medeiros
breno at google.com
Mon Sep 26 21:51:52 UTC 2011
Re-sending only the *.txt since the *.pdf was too large for list posting
On Mon, Sep 26, 2011 at 14:48, Breno de Medeiros <breno at google.com> wrote:
> Progress report for last week: Wrote a mini-spec on response types.
>
> Next: Will write a spec on single-signout that will become an
> important part of the session management spec.
>
> On Mon, Sep 26, 2011 at 11:00, Nat Sakimura <sakimura at gmail.com> wrote:
> > Dear Connectors:
> > Here is a friendly reminder for the call:
> > OpenID ABC WG has scheduled a conference for:
> > 7:00 AM Japan Standard Time on Tuesday
> > 6:00 PM EDT
> > 3:00 PM PDT
> > Conference Room Number: 1051580
> > Subject: Regular Spec Call
> > Details:
> >
> >
> > To use the HiDef Conferencing service, you may call from:
> > Skype:
> > Participants: +9900827041051580
> > Call Toll:
> > United States: +1 (201) 793-9022
> > Canada: +1 (201) 793-9022
> > Austria: +43 (0) 720881948
> > Belgium: +32 (0) 7 0357134
> > France: +33 (0) 826109071
> > Germany: +49 01805009527
> > Ireland: +353 (0) 818270968
> > Italy: +39 691717889
> > --
> > Nat Sakimura (=nat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> >
>
>
>
> --
> --Breno
>
--
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110926/5779a93c/attachment.html>
-------------- next part --------------
Draft B. de Medeiros, Ed.
M. Scurtescu
Google
P. Tarjan
Facebook
September 22, 2011
OAuth2 Multiple Response Type Encoding Practices
Abstract
This specification aims to provide guidance on proper encoding of
responses to OAuth2 Authorization requests, where the request
specifies a response type including space characters.
This specification also serves as the registration document for
several specific new response types, in accordance with the
stipulations of the OAuth Parameters Registry.
de Medeiros, et al. [Page 1]
Additional OAuth2 Response Type-draft 1 September 2011
Table of Contents
1. Requirements Notation and Conventions . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encoding Multiple-valued Response Types . . . . . . . . . . . 5
4. Id Token Response Type . . . . . . . . . . . . . . . . . . . . 6
5. None Response Type . . . . . . . . . . . . . . . . . . . . . . 7
6. Registration of Some Multiple-Valued Response Type
Combinations . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
de Medeiros, et al. [Page 2]
Additional OAuth2 Response Type-draft 1 September 2011
1. Requirements Notation and Conventions
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] .
Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
de Medeiros, et al. [Page 3]
Additional OAuth2 Response Type-draft 1 September 2011
2. Terminology
The following definitions define additional terminology used in this
specification in addition to those defined in OAuth 2.0 [OAuth.2.0].
Client and Server In the traditional client-server authentication
model, the client requests an access restricted resource
(protected resource) on the server by authenticating with the
server using the resource owner's credentials.
Authorization Endpoint A web resource mantained by the server, and
used to obtain authorization (grant) from the resource owner via
user-agent redirection.
Response Type The client informs the authorization server of the
desired authorization processing flow using the parameter
response_type.
Authorization Endpoint Response Type Registry Process established by
the OAuth2 specification for the registration of new response_type
parameters.
Multiple-valued Response Types The OAuth2 specification allows for
registration of space-separated response_type values. If a
response type contains one of more space characters (%20), it is
compared as a space-delimited list of values in which the order of
values does not matter.
de Medeiros, et al. [Page 4]
Additional OAuth2 Response Type-draft 1 September 2011
3. Encoding Multiple-valued Response Types
This specification does not provide guidance if, in a request,
response_type includes a value that requires the server to return
data partially encoded in the query string and partially encoded in
the fragment.
Otherwise, if a multiple-valued response type is defined, then it is
RECOMMENDED that the following encoding rules be applied for the
issued response.
If, in a request, response_type includes only values that require the
server to return data fully encoded within the query string then the
returned data in the response for this multiple-valued response_type
MUST be fully encoded within the query string. This recommendation
applies to both success and error responses.
If, in a request, response_type includes any value that requires the
server to return data fully encoded within the fragment then the
returned data in the response for this multiple-valued response_type
MUST be fully encoded within the fragment. This recommendation
applies to both success and error responses.
Rationale: Whenever response_type values include fragment-encoded
parts, a user-agent client component must be involved to complete
processing of the response. If a new query parameter is added to the
client URI, it will cause the user-agent to re-fetch the client URI,
causing discontinuity of operation of the user-agent-based client
components. If instead only fragment encoding is used, the user-
agent will simply re-active the client component, at which time this
component may process the fragment and also convey any parameters to
a client host as necessary, e.g., via XmlHttpRequest. Therefore,
full fragment encoding always results in lower latency for response
processing.
de Medeiros, et al. [Page 5]
Additional OAuth2 Response Type-draft 1 September 2011
4. Id Token Response Type
This section registers a new response type, the id_token, in
accordance with the stipulations in the OAuth2 specification, Section
8.4. The intended purpose of the id_token is that it MUST provide an
assertion of the identity of the resource owner as understood by the
server. The assertion MUST specify a targeted audience, e.g. the
requesting client. However, the specific semantics of the assertion
and how it can be validated are not specified in this document.
id_token If supplied as the response_type parameter in an OAuth2
Authorization Request, a successful response should include the
parameter id_token encoded in the fragment of the response URI.
Returning the id_token in a fragment reduces the likelihood that the
id_token leaks during transport and mitigates the associated risks to
the privacy of the user (resource owner).
de Medeiros, et al. [Page 6]
Additional OAuth2 Response Type-draft 1 September 2011
5. None Response Type
This section registers the response type none, in accordance with the
stipulations in the OAuth2 specification, Section 8.4. The intended
purpose is to enable use cases where a party requests the server to
register a grant of access to a protected resource on behalf of a
client but requires no access credentials to be returned to the
client at that time. The means by which the client eventually
obtains the access credentials is left unspecified here.
One scenario is where a user wishes to purchase an application from a
market, and desires to authorize application installation and grant
the application access to protected resources in a single step.
However, since the user is not presently interacting with the (not
yet active) application, it is not appropriate to return access
credentials simultaneously to the authorization step.
none When supplied as the response_type parameter in an OAuth2
authorization request, the Authorization server SHOULD NOT return
an OAuth2 code nor a token in a succesful response to the grant
request. If a redirect_uri is supplied, the user-agent SHOULD be
redirected there after granting or denying access. The request
MAY include a state parameter, and if so the server MUST echo its
value by adding it to the redirect_uri when issuing a successful
response. Any parameters added to the redirect_uri should be
query encoded. This applies to both successful responses or error
responses.
The response type none SHOULD NOT be combined with other response
types.
de Medeiros, et al. [Page 7]
Additional OAuth2 Response Type-draft 1 September 2011
6. Registration of Some Multiple-Valued Response Type Combinations
This section registers combinations of the values code, token, and
id_token, which are each individually registered response types.
code token When supplied as the value for the response_type
parameter, a successful response MUST include both an access token
and an authorization code as defined in the OAuth2 specification.
Both successful and error responses SHOULD be fragment-encoded.
code id_token When supplied as the value for the response_type
parameter, a successful response MUST include both an
authorization code as well as an id_token. Both success and error
responses SHOULD be fragment-encoded.
id_token token When supplied as the value for the response_type
parameter, a successful response MUST include both an access token
as well as an id_token. Both success and error responses SHOULD
be fragment-encoded.
code id_token token When supplied as the value for the response_type
parameter, a successful response MUST include an authorization
code, an id_token, and an access token. Both success and error
responses SHOULD be fragment-encoded.
A non-normative request/response example as issued/received by the
user-agent:
GET https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&state=af0ifjsldkj HTTP/1.1
HTTP/1.1 302 Found
Location: https://client.example.com/#
access_token=SlAV32hkKG&
token_type=bearer&
id_token=1234567.SlAV32hkKG.abcde1234&
expires_in=3600&
&state=af0ifjsldkj
de Medeiros, et al. [Page 8]
Additional OAuth2 Response Type-draft 1 September 2011
7. Normative References
[OAuth.2.0]
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "OAuth
2.0 Authorization Protocol", July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[W3C.REC-html401-19991224]
Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
de Medeiros, et al. [Page 9]
Additional OAuth2 Response Type-draft 1 September 2011
Appendix A. Acknowledgements
The OpenID Community would like to thank the following people for the
work they've done in the drafting and editing of this specification.
Naveen Agarwal (naa at google.com), Google
Breno de Medeiros (breno at google.com), Google
David Recordon (dr at fb.com), Facebook
Marius Scurtescu (mscurtescu at google.com), Google
Paul Tarjan (pt at fb.com), Facebook
de Medeiros, et al. [Page 10]
Additional OAuth2 Response Type-draft 1 September 2011
Appendix B. Document History
[[ To be removed from the final specification ]]
-01
o Initial draft
de Medeiros, et al. [Page 11]
Additional OAuth2 Response Type-draft 1 September 2011
Authors' Addresses
Breno (editor)
Google, Inc.
Email: breno at google.com
Marius
Google, Inc.
Email: mscurtescu at google.com
Paul
Facebook
Email: pt at fb.com
de Medeiros, et al. [Page 12]
More information about the Openid-specs-ab
mailing list