[OAUTH-WG] Timely review request: pre-draft-17

[Eran Hammer-Lahav]

I have started sharing my planned changes for ­17:

https://github.com/hueniverse/draft-ietf-oauth

Change log:

https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028
f66708427961a1bc102#diff-3


My main focus right now is to clarify client types, registration, and
identification, as well as tweak the registration requirements for
redirection URIs. This is still very raw. However, I would very much like
to get feedback about the following sections:

1.1.1.  Client Types
1.2.  Client Registration

2.1.1.  Redirection URI


In section 2.1.1, please note that it includes many new normative
requirements, but in practice, they mostly boil down to the requirement to
register a redirection URI for using the implicit grant type as well as
using the authorization code with a public client (new term for describing
client incapable of keeping secrets).

I have turned the spec around, making registered redirection URIs the
default, and using the parameter as an optional feature.

Feedback is very much appreciated as we only have a few more days before I
have to push out -17 and would like a few more eyes looking at the new
text before published.

I am still not ready to share changes to section 3. Also, I have a long
list of additional changes raised on the list.

Thanks,

EHL




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt

[Thomas Hardjono]

Thanks Barry.

Could you please add me to the OAUTH WG Agenda for a presentation on UMA.
I will send you the slides before July 22nd.

Thanks again.

Regards.

/thomas/



From: barryleiba.mailing.li...@gmail.com [barryleiba.mailing.li...@gmail.com] 
On Behalf Of Barry Leiba [barryle...@computer.org]
Sent: Monday, July 04, 2011 12:12 PM
To: Thomas Hardjono
Cc: oauth (oauth@ietf.org)
Subject: Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: 
draft-hardjono-oauth-umacore-00.txt

> FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.0.
>
> Hopefully we can present/discuss it at IETF81 in Quebec City.

The chairs will be happy to accept a presentation/discussion on this
as time permits.  That means it will go at the end of the agenda, and
we will only get to it if other discussions finish with enough time
for this.

It would help if you sent us slides to include in the meeting
materials.  We'll include them in the materials whether or not there's
time to present and discuss them, so they'll be part of the permanent
record, and so people can look them over.

I expect that we'll set the deadline for slide submissions at end of
day Friday, 22 July.  Send them to the chairs at
.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

[Brian Campbell]

Either way.  It could stay in there, if you want to show a concrete
example of an extension grant type.   Or it could be removed too -
draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer will
have plenty of examples.



On Mon, Jul 4, 2011 at 12:54 PM, Eran Hammer-Lahav  wrote:
> What about the example using SAML assertion?
> From: Brian Campbell 
> Date: Mon, 4 Jul 2011 11:42:21 -0700
> To: Eran Hammer-lahav 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
> subsection on assertions
>
> I believe the new assertion draft covers it and this change can be
> sidelined as long as the new draft has WG support to move forward.
> On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav 
> wrote:
>
> In light of the new assertion draft, do we still want to make this change?
> EHL
> From: Brian Campbell 
> Date: Tue, 24 May 2011 07:25:12 -0700
> To: oauth 
> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection
> on assertions
> One of the action items out of yesterday's meeting was to draft some
> text for a section 4.5.1 in core that defined the optional but
> recommended use of an "assertion" parameter for extension grants where
> the use of a single parameter to carry the grant/assertion was
> possible.  Below is a first cut at some proposed text that hopefully
> avoids some of the awkwardness that EHL described in previous attempts
> to introduce such a parameter.  Comments or edits or editorial
> improvements are, of course, welcome.  But I think this hopefully
> captures the intent of what was discussed yesterday (and before).
> If we get some consensus to make this change, I think a couple of
> other actions are implied.
> - The IANA assertion parameter registration request
> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1)
> should be removed from the SAML draft and put into
> http://tools.ietf.org/html/draft-ietf-oauth-v2
> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec
> will change the parameter it uses from jwt to assertion and drop the
> registration request for jwt
> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1)
> --- proposed text for sections 4.5 & 4.5.1 ---
> 4.5. Extensions
>    The client uses an extension grant type by specifying the grant type
>    using an absolute URI (defined by the authorization server) as the
>    value of the "grant_type" parameter of the token endpoint, and by
>    adding any additional parameters necessary.
>    If the access token request is valid and authorized, the
>    authorization server issues an access token and optional refresh
>    token as described in Section 5.1.  If the request failed client
>    authentication or is invalid, the authorization server returns an
>    error response as described in Section 5.2.
> 4.5.1 Assertion Based Extension Grants
>   If the value of the extension grant can be serialized into a single
>   parameter, as is case with a number of assertion formats, it is
>   RECOMMENDED that that a parameter named "assertion" be used to
>   carry the value.
>    assertion
>  REQUIRED.  The assertion. The format and encoding of the
>  assertion is defined by the authorization server or
>  extension specification.
>    For example, to request an access token using a SAML 2.0 assertion
>    grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
>    makes the following HTTP request using transport-layer security (line
>    breaks are for display purposes only):
>    POST /token HTTP/1.1
>    Host: server.example.com
>    Content-Type: application/x-www-form-urlencoded
>    grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
>    bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
>    [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft 16 review notes

[Eran Hammer-Lahav]

As I go over recent feedback, anything that requires additional text will be 
bounced back to the list for new proposed language. I need to receive it by 
noon PT Thur, to be included in –17 (assuming no objections).

EHL

From: Barry Leiba mailto:barryle...@computer.org>>
Date: Mon, 4 Jul 2011 09:16:28 -0700
To: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft 16 review notes

On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav 
mailto:e...@hueniverse.com>> wrote:
Need proposed text.
...
Need proposed text.
...
Need proposed text.

I will add to this that at this stage in the document development, any
requests for changes need to be accompanied by specific proposed text.
If you absolutely can't come up with anything, you may make the
comment anyway and explain why you're at a loss for text, but realize
that the editors might not be able to incorporate your suggestion,
though they will try.

The editors plan to submit a -17 version this week, and when they do
we will start Working Group Last Call.  We will expect ALL suggestions
for changes to be specific about what text they propose.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 16 Security Considerations additions

[Eran Hammer-Lahav]

This needs to be reworked to reflect reality. The state value must be shared 
with the resource owner's browser and authorization server, so it is not really 
a secret known only to the client…

EHL

From: Mark Mcgloin mailto:mark.mcgl...@ie.ibm.com>>
Date: Wed, 1 Jun 2011 11:28:33 -0700
To: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>
Cc: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions


Hi Torsten

It was implicit that the state parameter would be secret and not guessable
but that it probably worth spelling out, as you and Breno state. Here is a
modified version


CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an attacker to
obtain authorization to OAuth Protected Resources without the consent of
the User.
The state parameter should be used to mitigate against CSRF attacks,
particularly for login CSRF attacks. It is strongly RECOMMENDED that the
client sends the state parameter with authorization requests to the
authorization server. The state parameter MUST be non-guessable and MUST be
a secret only accessible to the client. The authorization server will send
it in the response when redirecting the user to back to the client which
MUST then validate the state parameter matches on the response.


Regards
Mark

Torsten Lodderstedt mailto:tors...@lodderstedt.net>> 
wrote on 01/06/2011 09:11:31:

From:

Torsten Lodderstedt mailto:tors...@lodderstedt.net>>

To:

Mark Mcgloin/Ireland/IBM@IBMIE

Cc:

oauth@ietf.org

Date:

01/06/2011 09:11

Subject:

Re: [OAUTH-WG] Draft 16 Security Considerations additions


Hi Mark,

Am 31.05.2011 22:58, schrieb Mark Mcgloin:
> Eran
>
> Here are some additional sections to add to the next draft under
security
> considerations
>
> CSRF
> Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
> requests are transmitted from a user that the website trusts or has
> authenticated. CSRF attacks on OAuth approvals can allow an attacker to
> obtain authorization to OAuth Protected Resources without the consent
of
> the User.
> The state parameter should be used to mitigate against CSRF attacks,
> particularly for login CSRF attacks. It is strongly RECOMMENDED that
the
> client sends the state parameter with authorization requests to the
> authorization server. The authorization server will send it in the
response
> when redirecting the user to back to the client which SHOULD then
validate
> the state parameter matches on the response.

As far as I understand, the goal of the countermeasure is to bind the
authz flow to a certain user agent (instance). So client must verify
that the state parameter (or any other URL parameter?) matches some data
found in the user agent itself before further processing the authz code.

Breno explained it as follows:
-
- Client or user-agent generates a secret.
- The secret is stored in a location accessible only by the client or
the user agent (i.e., protected by same-origin policy). E.g.: DOM
variable (protected by javascript or other DOM-binding language's
enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc.
- The secret is attached to the state before a request is issued by the
client
- When the response is received, before accepting the token or code, the
client consults the user agent state and rejects the response altogether
if the state does not match the user agent's stored value.


I would suggest to incorporate this into the decription:

It is strongly RECOMMENDED that the client sends the state parameter
with authorization requests to the authorization server. _The state
parameter MUST refer to a secret value retained at the user agent._
The authorization server will send the _state parameter_ in the
response when redirecting the user to back to the client which
_MUST_ then validate the state parameter_'s value against the secret
value in the user agent_.


regards,
Torsten.





> Clickjacking
> Clickjacking is the process of tricking users into revealing
confidential
> information or taking control of their computer while clicking on
seemingly
> innocuous web pages. In more detail, a malicious site loads the target
site
> in a transparent iframe overlaid on top of a set of dummy buttons which
are
> carefully constructed to be placed directly under important buttons on
the
> target site. When a user clicks a visible button, they are actually
> clicking a button (such as an "Authorize" button) on the hidden page.
> To prevent clickjacking (and phishing attacks), native applications
SHOULD
> use external browsers instead of embedding browsers in an iFrame when
> requesting end-user authorization. For newer browsers, avoidance of
iFrames
> can be enforced server side by using the X-FRAME-OPTION header. This
header
> can have two values, deny and 

Re: [OAUTH-WG] Section 10.1 (Client authentication)

[Eran Hammer-Lahav]

It's a pointless MUST given how undefined the requirements are. It will only be 
understood by security experts and they don't really need it. At a minimum, it 
needs some examples.

EHL

From: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, OAuth 
WG mailto:oauth@ietf.org>>
Subject: Section 10.1 (Client authentication)

Hi Eran,

would you please add the following sentence (which was contained in the
original security considerations text) to the second paragraph of
section 1.0.1?

Alternatively, authorization servers MUST utilize
other means than client authentication to achieve their security
objectives.


I think it's important to state that authorization server should
consider alternative way to validate the client identity if secrets
cannot be used. The security threat document also suggest some.

regards,
Torsten.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

[Eran Hammer-Lahav]

What about the example using SAML assertion?

From: Brian Campbell 
mailto:bcampb...@pingidentity.com>>
Date: Mon, 4 Jul 2011 11:42:21 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 
subsection on assertions

I believe the new assertion draft covers it and this change can be
sidelined as long as the new draft has WG support to move forward.

On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav 
mailto:e...@hueniverse.com>> wrote:
In light of the new assertion draft, do we still want to make this change?
EHL
From: Brian Campbell 
mailto:bcampb...@pingidentity.com>>
Date: Tue, 24 May 2011 07:25:12 -0700
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection
on assertions

One of the action items out of yesterday's meeting was to draft some
text for a section 4.5.1 in core that defined the optional but
recommended use of an "assertion" parameter for extension grants where
the use of a single parameter to carry the grant/assertion was
possible.  Below is a first cut at some proposed text that hopefully
avoids some of the awkwardness that EHL described in previous attempts
to introduce such a parameter.  Comments or edits or editorial
improvements are, of course, welcome.  But I think this hopefully
captures the intent of what was discussed yesterday (and before).
If we get some consensus to make this change, I think a couple of
other actions are implied.
- The IANA assertion parameter registration request
(http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1)
should be removed from the SAML draft and put into
http://tools.ietf.org/html/draft-ietf-oauth-v2
- The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec
will change the parameter it uses from jwt to assertion and drop the
registration request for jwt
(http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1)

--- proposed text for sections 4.5 & 4.5.1 ---
4.5. Extensions
   The client uses an extension grant type by specifying the grant type
   using an absolute URI (defined by the authorization server) as the
   value of the "grant_type" parameter of the token endpoint, and by
   adding any additional parameters necessary.
   If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request failed client
   authentication or is invalid, the authorization server returns an
   error response as described in Section 5.2.
4.5.1 Assertion Based Extension Grants
  If the value of the extension grant can be serialized into a single
  parameter, as is case with a number of assertion formats, it is
  RECOMMENDED that that a parameter named "assertion" be used to
  carry the value.
   assertion
 REQUIRED.  The assertion. The format and encoding of the
 assertion is defined by the authorization server or
 extension specification.
   For example, to request an access token using a SAML 2.0 assertion
   grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
   makes the following HTTP request using transport-layer security (line
   breaks are for display purposes only):
   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded
   grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
   bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
   [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

[Brian Campbell]

I believe the new assertion draft covers it and this change can be
sidelined as long as the new draft has WG support to move forward.

On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav  wrote:
> In light of the new assertion draft, do we still want to make this change?
> EHL
> From: Brian Campbell 
> Date: Tue, 24 May 2011 07:25:12 -0700
> To: oauth 
> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection
> on assertions
>
> One of the action items out of yesterday's meeting was to draft some
> text for a section 4.5.1 in core that defined the optional but
> recommended use of an "assertion" parameter for extension grants where
> the use of a single parameter to carry the grant/assertion was
> possible.  Below is a first cut at some proposed text that hopefully
> avoids some of the awkwardness that EHL described in previous attempts
> to introduce such a parameter.  Comments or edits or editorial
> improvements are, of course, welcome.  But I think this hopefully
> captures the intent of what was discussed yesterday (and before).
> If we get some consensus to make this change, I think a couple of
> other actions are implied.
> - The IANA assertion parameter registration request
> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1)
> should be removed from the SAML draft and put into
> http://tools.ietf.org/html/draft-ietf-oauth-v2
> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec
> will change the parameter it uses from jwt to assertion and drop the
> registration request for jwt
> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1)
>
> --- proposed text for sections 4.5 & 4.5.1 ---
> 4.5. Extensions
>    The client uses an extension grant type by specifying the grant type
>    using an absolute URI (defined by the authorization server) as the
>    value of the "grant_type" parameter of the token endpoint, and by
>    adding any additional parameters necessary.
>    If the access token request is valid and authorized, the
>    authorization server issues an access token and optional refresh
>    token as described in Section 5.1.  If the request failed client
>    authentication or is invalid, the authorization server returns an
>    error response as described in Section 5.2.
> 4.5.1 Assertion Based Extension Grants
>   If the value of the extension grant can be serialized into a single
>   parameter, as is case with a number of assertion formats, it is
>   RECOMMENDED that that a parameter named "assertion" be used to
>   carry the value.
>    assertion
>  REQUIRED.  The assertion. The format and encoding of the
>  assertion is defined by the authorization server or
>  extension specification.
>    For example, to request an access token using a SAML 2.0 assertion
>    grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
>    makes the following HTTP request using transport-layer security (line
>    breaks are for display purposes only):
>    POST /token HTTP/1.1
>    Host: server.example.com
>    Content-Type: application/x-www-form-urlencoded
>    grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
>    bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
>    [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : OAuth 2.0 Assertion Profile
Author(s)   : Michael B. Jones
  Brian Campbell
  Yaron Goland
Filename: draft-ietf-oauth-assertions-00.txt
Pages   : 14
Date: 2011-07-04

   This specification provides a general framework for the use of
   assertions as client credentials and/or authorization grants with
   OAuth 2.0.  It includes a generic mechanism for transporting
   assertions during interactions with a token endpoint, as wells as
   rules for the content and processing of those assertions.  The intent
   is to provide an enhanced security profile by using derived values
   such as signatures or HMACs, as well as facilitate the use of OAuth
   2.0 in client-server integration scenarios where the end-user may not
   be present.

   This specification only defines abstract messsage flow and assertion
   content.  Actual use requires implementation of a companion protocol
   binding specification.  Additional profile documents provide standard
   representations in formats such as SAML and JWT.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-assertions-00.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

[Eran Hammer-Lahav]

In light of the new assertion draft, do we still want to make this change?

EHL

From: Brian Campbell 
mailto:bcampb...@pingidentity.com>>
Date: Tue, 24 May 2011 07:25:12 -0700
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on 
assertions

One of the action items out of yesterday's meeting was to draft some
text for a section 4.5.1 in core that defined the optional but
recommended use of an "assertion" parameter for extension grants where
the use of a single parameter to carry the grant/assertion was
possible.  Below is a first cut at some proposed text that hopefully
avoids some of the awkwardness that EHL described in previous attempts
to introduce such a parameter.  Comments or edits or editorial
improvements are, of course, welcome.  But I think this hopefully
captures the intent of what was discussed yesterday (and before).

If we get some consensus to make this change, I think a couple of
other actions are implied.

- The IANA assertion parameter registration request
(http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1)
should be removed from the SAML draft and put into
http://tools.ietf.org/html/draft-ietf-oauth-v2

- The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec
will change the parameter it uses from jwt to assertion and drop the
registration request for jwt
(http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1)


--- proposed text for sections 4.5 & 4.5.1 ---

4.5. Extensions

   The client uses an extension grant type by specifying the grant type
   using an absolute URI (defined by the authorization server) as the
   value of the "grant_type" parameter of the token endpoint, and by
   adding any additional parameters necessary.

   If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request failed client
   authentication or is invalid, the authorization server returns an
   error response as described in Section 5.2.

4.5.1 Assertion Based Extension Grants

  If the value of the extension grant can be serialized into a single
  parameter, as is case with a number of assertion formats, it is
  RECOMMENDED that that a parameter named "assertion" be used to
  carry the value.

   assertion
 REQUIRED.  The assertion. The format and encoding of the
 assertion is defined by the authorization server or
 extension specification.

   For example, to request an access token using a SAML 2.0 assertion
   grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
   makes the following HTTP request using transport-layer security (line
   breaks are for display purposes only):

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
   bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
   [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call For Agenda Items for IETF#81

[Barry Leiba]

> it is time to think about the agenda for the IETF#81 meeting in Quebec City.

Adding to this, in case folks haven't looked at the draft IETF agenda:
we're currently scheduled from 9 to 11:30 EDT (13:00 to 15:30 UTC) on
Wednesday morning, 27 July -- BUT THAT MIGHT CHANGE.  There will, as
always, be arrangements for remote participation for those who can't
make it in person.

Presenters will be asked to have presentation slides in to the chairs
by the end of the day Saturday, 23 July, so we can post them to the
meeting materials page with plenty of time for all participants to
review them.

Meeting materials page: https://datatracker.ietf.org/meeting/81/materials.html

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 16 comment

[Eran Hammer-Lahav]

Section 3:


   In addition, the authorization server MAY allow unauthenticated
   access token requests when the client identity does not matter (e.g.
   anonymous client) or when the client identity is established via
   other means.  For readability purposes only, this specification is
   written under the assumption that the authorization server requires
   some form of client authentication.  However, such language does not
   affect the authorization server's discretion in allowing

   unauthenticated client requests.

From: Shane Weeden mailto:swee...@au1.ibm.com>>
Date: Sun, 22 May 2011 21:40:22 -0700
To: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Draft 16 comment


First, I'd like to add my support for Brian Eaton's comments on Draft 16.
They actually helped clarify the comment I have below


I found section 9 to be in contradiction to a part of section 6. In
particular in section 9:

Native applications SHOULD use the authorization code grant type flow
without client password credentials (due to their inability to keep
the credentials confidential) to obtain short-lived access tokens,
and use refresh tokens to maintain access.

In section 6 the specification is quite clear that client authentication is
REQUIRED for the use of refresh tokens:

   The authorization server MUST validate the client credentials, ensure
   that the refresh token was issued to the authenticated client,
   validate the refresh token, and verify that the resource owner's
   authorization is still valid.


My  understanding is that refresh tokens are being used as a kind of
long-lived, rolling "instance secret" for the native application and
represent the grant authorized by the end user during initial establishment
of the authorization code which is used to get the first refresh token.

It seems to me this use case needs to be allowed for in the wording of
section 6.

Regards,
Shane.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Call For Agenda Items for IETF#81

[Hannes Tschofenig]

Hi all, 

it is time to think about the agenda for the IETF#81 meeting in Quebec City.

Since we are planning to complete the current working group documents our focus 
will be on the working group items. 

Please sent me a mail off-list whether you are able to present your document. 

Here is a strawman agenda proposal: 

--

1) Agenda Bashing, and WG Status

2) The OAuth 2.0 Authorization Protocol
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

Eran is going to submit a version -17 in time for the submission deadline. 
We plan to start a WGLC after the submission deadline (with a longer review 
period due to the IETF meeting).

3) The OAuth 2.0 Protocol: Bearer Tokens
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/

4) HTTP Authentication: MAC Access Authentication
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/

5) Assertions
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
http://datatracker.ietf.org/doc/draft-mortimore-oauth-assertions/

6) OAuth 2.0 Threat Model and Security Considerations
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/

7) Conclusion & Next Steps 

We are also open to discuss other items during our working group meeting, if 
time permits. 

--

To make use of the IETF week I would encourage everyone to read through these 
documents carefully. 

Ciao
Hannes, Barry, Blaine

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft 16 review notes

[Barry Leiba]

On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav  wrote:
> Need proposed text.
...
> Need proposed text.
...
> Need proposed text.

I will add to this that at this stage in the document development, any
requests for changes need to be accompanied by specific proposed text.
 If you absolutely can't come up with anything, you may make the
comment anyway and explain why you're at a loss for text, but realize
that the editors might not be able to incorporate your suggestion,
though they will try.

The editors plan to submit a -17 version this week, and when they do
we will start Working Group Last Call.  We will expect ALL suggestions
for changes to be specific about what text they propose.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt

[Barry Leiba]

> FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.0.
>
> Hopefully we can present/discuss it at IETF81 in Quebec City.

The chairs will be happy to accept a presentation/discussion on this
as time permits.  That means it will go at the end of the agenda, and
we will only get to it if other discussions finish with enough time
for this.

It would help if you sent us slides to include in the meeting
materials.  We'll include them in the materials whether or not there's
time to present and discuss them, so they'll be part of the permanent
record, and so people can look them over.

I expect that we'll set the deadline for slide submissions at end of
day Friday, 22 July.  Send them to the chairs at
.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reminder of draft submission deadlines

[Barry Leiba]

Important reminder to all draft editors:

The deadline for submissions of -00 version drafts is TODAY, 4 July,
at 17:00 PDT (23:59+ UTC).

The deadline for submissions of later version drafts is NEXT MONDAY,
11 July, at 17:00 PDT (23:59+ UTC).

Please don't miss the deadlines if you have drafts to submit.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth