Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Eran Hammer-Lahav]

First, congrats on the new member of the Eaton family.

> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Tuesday, December 08, 2009 10:43 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft
> 
> On Mon, Dec 7, 2009 at 11:52 PM, Eran Hammer-Lahav
>  wrote:
> > Can you list the use cases it doesn't meet? This is largely a cosmetic
> > rewrite of 1.0 with the exception of directly supporting form-encoded
> > parameters which is still being discussed. Your reference is to a post about
> mostly non-HTTP use cases.
> 
> There are basically two use cases for the crypto in OAuth 1.0, and one major
> problem.
> 
> Major problem: people can't figure out the signature base string.
> The new authentication spec does nothing to fix this, which is a shame.  
> It is
> solvable.

Can you offer alternatives other than including a base64 copy of what is being 
signed.

> Use case #1: security for people who won't use https.
> We seem to have concluded that this isn't achievable. [1]

HTTPS will be a required part of the protocol. The question is, are we going to 
accommodate the case where HTTPS is not desirable for every protected resource 
request? There seems to be consensus that yes.

> Use case #2: security for people who need to send messages through
> untrusted third-parties.
> The new authentication spec makes this much, much harder.
>
> Here are a few examples of places where people are using OAuth to send
> messages through untrusted third-parties.  Every single one of these use
> cases is broken by the token-auth spec [2].  If we can't solve these problems,
> there is very little point in message authentication at all.
> 
> For example:
> - signed URLs embedded in the browser [3]
> - opensocial identity parameters [4]
> - google-specific identity parameters [5]
> - intermediate xmpp servers [6]
> - intermediate sip servers [6]

What about the draft breaks these? Is it the need to access the raw HTTP 
request URI? That is the only difference between the token scheme and the 
current OAuth signature base string. This wasn't a new idea - I have asked 
about this more than once and the consensus was that it is not a problem. If it 
is, it certainly makes a difference and the side effect was not intentional.

EHL

> We should be trying to make those use cases *easier*, not make them
> impossible.  If we push a new OAuth spec that drops these use cases, we've
> done more harm than good.
> 
> Cheers,
> Brian
> 
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00762.html
> [2] http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
> [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00689.html
> [4] http://www.opensocial.org/Technical-Resources/opensocial-spec-
> v09/Gadgets-API-Specification.html#gadgets.io.makeRequest
> [5]
> http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAut
> h
> [6] http://www.ietf.org/mail-archive/web/oauth/current/msg00513.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Eran Hammer-Lahav]

Thanks Dan.

> -Original Message-
> From: Dan Winship [mailto:dan.wins...@gmail.com]
> Sent: Tuesday, December 08, 2009 11:00 AM

> If Token/OAuth is not intended for use with Proxy-Authenticate/Proxy-
> Authorization, then you should say that explicitly near the beginning, and if
> not, then everywhere you say "WWW-Authenticate" or "Authorization", you
> need to allow for the proxy versions as well. (Maybe just by saying
> "whenever I say WWW-Authenticate, I mean 'either WWW-Authenticate or
> Proxy-Authenticate'.")

I'll get to this if this draft ever makes it to the other side.

> I know you said you don't care about typos, but "OWF" should be "OWS".
> 
> "rsassa-pkcs1-v1.5-sha-256" is way too long a name. :)

Trying to be descriptive. The current RSA-SHA1 means nothing without reading 
the spec (it might as well be 'R1').
 
> The grammar for method-list says
> 
> method-list = "method" "=" <"> 1#method-name <">
> 
> where "1#method-name" in RFC2616 ABNF means a comma-delimited list of
> method-name. But the text (4.2) and the example quoted above use a
> space-delimited list. (Likewise with coverage-list.)

Right. I wanted it to be space-delimited.
 
> The first paragraph of section 5 seems to say that clients MUST include a
> Authorization header when requesting a protected resource even if they
> don't know that it's protected. :)

Changed to 'when making an authenticated request'.

> In theory, the information in the Authentication-Error response could just be
> included in WWW-Authenticate...

I am actually going to try and use Authentication-Info (expending its use 
beyond Digest and making it applicable for errors, not just success). Keeping 
this in a separate header makes it easier I think to parse the challenge. No 
strong feelings here.

> If error-message is supposed to be localized then you should allow for the
> RFC 2183 grammar (or eventually, the grammar from the RFC that draft-
> reschke-rfc2183-in-http becomes).

OK.

> The "normalized request string" says it includes both the hostname and the
> request URI, which would be redundant. Maybe when you say "request
> resource URI" you mean just the Request-URI production from the Request-
> Line (ie, the path+query), not the actual complete request URI?

Yeah, that's what I mean.

> You should clarify that. Although if the user is behind a proxy then the
> Request-URI will be a complete URI rather than just the path+query. So you
> might want to say something like "the path and query components of the
> request URI, as they appear in the Request-Line"?

The request Request-URI exactly as it appears on HTTP 
Request-Line as defined by
RFC2616> section 5.1.2.

> There have been interoperability problems with Digest auth digest
> computation because people weren't sure if the quotes around attribute
> values were considered part of the value or not when computing the hash.
> You should be explicit.

We didn't get this one in OAuth 1.0 (plenty of other issues)... seems like an 
odd thing to fail on. I'll note it.

> "Any authentication attribute, with the exception of the "auth", which is
> assigned a value (including default values), are added to the normalized
> request string as follows" is hard to understand. I think what you mean is
> "Any attribute which is present in the Authorization header, with the
> exception of "auth", is added to the normalized request string as follows".

Ok.

> Hm... although 7.1 seems to suggest something else.
> I'm not at all sure what attributes are supposed to be included in the
> normalized request string now.

Fixed.

> Would probably be good to have an example of computing the string.

If this makes it to the other side, I'll add plenty of examples in the spirit 
of draft-hammer-oauth.

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

Re: [OAUTH-WG] Use Case: Adobe: HTTP based media delivery

[Gaurav Rastogi]

Hi Blaine,

Here is details on the use case regarding http token authentication based out 
of media delivery workflow currently being used by Adobe, several major US 
broadcasting companies, and CDN vendors. We are hoping to use http token 
authentication to solve some of the major pain points around media syndication 
and IPTV use cases.

thanks,
Gaurav

Adobe Systems.

On Jan 29, 2010, at 11:58 AM, Gaurav Rastogi wrote:

This proposal is to allow use of same token to access multiple
protected resource across different servers. At minimum making it
optional would help in wide variety of media delivery use cases.

Proposal details:
Exclude hostname and port number in normalized request string
creation. Another possible approach could be to allow modifications
of the subdomains as consistent with the name server RFC.

Background: Adobe Media Streaming (HTTP and RTMP) use cases.
Current Adobe's IPTV and web video services partners including large
media broadcasting companies, CDN services, and IPTV solutions vendors
all face the problem that multiple resources need to be used for
making a single web video experience.

In case of HTTP media streaming a single content delivery may comprise
of hundreds of individual http fragments served that are delivered
over multiple network connections using multiple media assets. In
addition, Advertising, DRM and License server API/interaction may also
be involved.

When dynamic streaming or multi-bit rate media is being streamed then
fragments from different versions of the asset are requested based on
real time network and client feedback. Client re-authorization can
result in high a latency and non-realtime system degrading the user
experience in wide variety of rich media solutions delivered over the
internet.

In several load balancing solutions like CENAME or request redirection
may modify server URI based on runtime considerations. Many CDN
workflows and global Internet services use such schemes. Having
mandatory hostname, which could have been modified, restricts use of
HTTP token obtained before the load balancing decision was made.

Example workflow
 +---+  +---+
 | C |--(A)-- credentials ->| Authorization |
 |  l  |<-(B)-- Access Token -| Server|
 | i |  +---+
 | e |
 | n |  +---+Access Token  +---+
 | t |  | W |--(C)- in HTTP header --->| Protected |
 |   |  | e |<-(D)-- API response -| Resource[0]   |
 |   |->| b |  +---+
 |   |  |   |Access Token  +---+
 |   |<-| S |--(E)- in HTTP header --->| Protected |
 |   |  | e |<-(F)-- API response -| Resource[i]   |
 |   |  | r |  +---+
 |   |  | V |Access Token  +---+
 |   |  | i |--(G)- in HTTP header --->| Protected |
 |   |  | c |<-(H)-- API response -| Resource[N]   |
 |   |  | e |  +---+
 +---+  +---+
 Figure 1.
In the above Figure 1, client uses a webservice which performs a single
authorization to obtain an opaque access token. It then uses the same access
token to request multiple protected resources without needing to re-authorize
every time a new resource is used.
C,D: Request for license to decrypt the HD content
E,F: Multiple requests for the media fragments for HD content
G,H: Change request for lower bit-rate content in case there is network
congestion or need for lower resources on client. This request may happen after
30 mins of the start of the rich media experience session.

Thanks,
Gaurav Rastogi
Adobe Systems



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

Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01

[Eran Hammer-Lahav]

> -Original Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Wednesday, February 03, 2010 10:19 PM
> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: RE: Comment on draft-hammer-http-token-auth-01
> 
> > I disagree. Voiding a token to stop supporting an algorithm is
> > perfectly reasonable and might not even require user involvement if the
> > refresh mechanism is (adopted and) used. And if the reason for this is
> > a broken algorithm, well, I would hope the tokens are voided, not just
> > used with the same secret and new algorithm.
> 
> Migrating to new algorithms is a very slow and tortuous process -- partly
> because an algorithm is rarely completely broken in a single instant. Even
> MD5
> is still safe for some purposes. Binding secrets to hash algorithms in the
> protocol (not just as a choice by one server) will make migrations that much
> harder.

What do you mean by 'binding secrets to hash algorithms in the protocol"?
 
> > I am not sure what you mean by "one app may only support SHA-1, while
> > another only supports SHA-256". Are you suggesting something like a
> > company with centralized token service but where each service using a
> > different set of algorithm, but still sharing the same token across
> > services? Sounds like a company in need of new management.
> 
> That is exactly what I am suggesting. Old apps, new apps, outsourced apps,
> legacy apps, white-label apps rebadged, app in this language, app in that
> language, apps in the cloud, apps from a merger...
> There is no way I expect perfect consistency in supported algorithms, but I
> do
> want to try to have SSO across these apps and a central token service for
> accessing their APIs.
> 
> I don't want to have to upgrade every single app (even the niche near
> end-of-life ones) to support a new algorithm before I can start using it
> anywhere. If a credential bound to a new algorithm is issued to a client, that
> client can no longer access apps that have not been upgraded -- or, worst
> still, the client is expected to manage multiple app-specific credentials
> where previously they used one.

This is a question for the group - is this a use case we want to support? Is it 
worth the complexity it adds?
 
> > > Breaking the existing model of HTTP authentication (1 scheme per
> > > mechanism) is the wrong approach.
> >
> > Not sure what you mean.
> 
> In most HTTP authentication mechanisms, knowing the scheme is sufficient
> to
> know the sort of credential required, the security properties, and if you have
> the code to support it. With Token, the credentials might be just a token, a
> token and shared secret, or a token and asymmetric key. With Token, you
> may or
> may not be safe from passive attacks, or active attacks; may or may not
> require lower-layer security; might have to do computationally-intensive
> public-key crypto or might only require trivial copy 'n paste.

That's OAuth 1.0 today, just to be clear.

> You have broken the model where the scheme means something about the
> type of
> credential and the security.

Not in practice. The server knows exactly what kind of credentials it is 
issuing and the client knows exactly what kind of credentials it is using. To 
suggest that just because the scheme does not include some label makes it 
broken is going too far. All I did was remove the ability to negotiate the 
authentication method, not make it completely arbitrary.

According to your analysis, adding the ability to negotiate the type of 
credentials or algorithm has the exact same problem because you can't tell what 
the client will choose. In my draft, the client is limited to what the server 
issued in the first place and what it is willing to accept.

If this is a real issue, it can only be solved be creating a scheme per 
credential type and potentially algorithm.

EHL

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

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[Eran Hammer-Lahav]

Just to be clear, I was referring to the case where a client can figure out how 
to obtain authorization and then authenticate without any pre-configuration. 
This means giving a discovery flow for each type of authorization option 
(desktop, mobile, web, etc.) with all the parameters needed for each (pop-up 
size, redirection URIs, extension parameters, digital TOS).

EHL

> -Original Message-
> From: John Panzer [mailto:jpan...@google.com]
> Sent: Wednesday, February 03, 2010 9:23 PM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> Au contraire (speaking only for myself).
> 
> On Wednesday, February 3, 2010, Eran Hammer-Lahav
>  wrote:
> > It doesn't feel like we have much interest at this level of 
> > interoperability at
> this point.
> >
> > EHL
> >
> >> -Original Message-
> >> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> >> Sent: Wednesday, February 03, 2010 5:38 AM
> >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
> >> authentication challenge?
> >>
> >> An authentication challenge (WWW-Authenticate header) defined in a
> >> spec for an authentication mechanism should be present, but only with
> >> details specific to that mechanism (eg list of MAC algorithms).
> >>
> >> I think there should be a totally separate WWW-Authenticate header
> >> specifically saying "a delegation flow can be used to access this
> >> resource". It should include details such as the URI to redirect the user 
> >> to.
> >>
> >> We really need this if we want to offer a web-style protocol with any
> >> semblance of interoperability. If we omit it because "clients need to
> >> know lots of other API-specific details anyway" then we wont have a
> >> path to get past that limitation in future.
> >>
> >>
> >> --
> >> James Manger
> >>
> >> > -Original Message-
> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> > Behalf Of Eran Hammer-Lahav
> >> > Sent: Thursday, 28 January 2010 2:12 PM
> >> > To: OAuth WG (oauth@ietf.org)
> >> > Subject: [OAUTH-WG] What are the primary criteria in issuing an
> >> > authentication challenge?
> >> >
> >> > An authentication challenge (to make sure we are all on the same
> >> > page) is something the server sends to the client when denying
> >> > access to a protected resource. The challenge can be as simple as
> >> > "use Basic", or complex as "use Digest with the following
> >> > parameters". OAuth 1.0 doesn't really use a challenge because it
> >> > was created for cases where the API calls are preconfigured and
> >> > hardcoded into the client. The client should never receive an OAuth
> >> > challenge the way the protocol was originally designed.
> >> >
> >> > In my token authentication draft I tried to propose multiple
> >> > mechanisms (not fully baked yet) for issuing a challenge and
> >> > allowing the client to figure out what to do next. Before producing
> >> > another draft, it is important to figure out what challenge model
> >> > we want to use. Here are the general options I came up with:
> >> >
> >> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
> >> > left on its own to figure out what to do next.
> >> >
> >> > 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> >> > need a new token go there". It is still not clear how this will
> >> > help the client given that getting a token is likely it include
> >> > many different options, and to fully address this we need to dig
> >> > deep into discovery which was left out of scope.
> >> >
> >> > 3. Token attributes - the server informs the client of the kind of
> >> > tokens accepted (based on their cryptographic properties or the
> >> > resource-set/realm they are good for). This is just like #2 but
> >> > with the ability for the server to support more than one token type
> >> > per resource.
> >> >
> >> > Question: Is the ability for a single token-protected resource to
> >> > support more than one token type (say Plain+SSL *and* HMAC-256)
> >> > part of our requirements? If not, there is no reason at all for the
> >> > challenge to include anything other than #1 or #2 (probably defined
> >> > as a future extension).
> >> >
> >> > EHL
> >> >
> >> > ___
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > ht 
> 
> --
> --
> John Panzer / Google
> jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01

[Manger, James H]

> I disagree. Voiding a token to stop supporting an algorithm is
> perfectly reasonable and might not even require user involvement if the
> refresh mechanism is (adopted and) used. And if the reason for this is
> a broken algorithm, well, I would hope the tokens are voided, not just
> used with the same secret and new algorithm.

Migrating to new algorithms is a very slow and tortuous process -- partly 
because an algorithm is rarely completely broken in a single instant. Even MD5 
is still safe for some purposes. Binding secrets to hash algorithms in the 
protocol (not just as a choice by one server) will make migrations that much 
harder.


> I am not sure what you mean by "one app may only support SHA-1, while
> another only supports SHA-256". Are you suggesting something like a
> company with centralized token service but where each service using a
> different set of algorithm, but still sharing the same token across
> services? Sounds like a company in need of new management.

That is exactly what I am suggesting. Old apps, new apps, outsourced apps, 
legacy apps, white-label apps rebadged, app in this language, app in that 
language, apps in the cloud, apps from a merger...
There is no way I expect perfect consistency in supported algorithms, but I do 
want to try to have SSO across these apps and a central token service for 
accessing their APIs.

I don't want to have to upgrade every single app (even the niche near 
end-of-life ones) to support a new algorithm before I can start using it 
anywhere. If a credential bound to a new algorithm is issued to a client, that 
client can no longer access apps that have not been upgraded -- or, worst 
still, the client is expected to manage multiple app-specific credentials 
where previously they used one.


> > Breaking the existing model of HTTP authentication (1 scheme per
> > mechanism) is the wrong approach.
>
> Not sure what you mean.

In most HTTP authentication mechanisms, knowing the scheme is sufficient to 
know the sort of credential required, the security properties, and if you have 
the code to support it. With Token, the credentials might be just a token, a 
token and shared secret, or a token and asymmetric key. With Token, you may or 
may not be safe from passive attacks, or active attacks; may or may not 
require lower-layer security; might have to do computationally-intensive 
public-key crypto or might only require trivial copy 'n paste.

You have broken the model where the scheme means something about the type of 
credential and the security.

--
James Manger


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[John Panzer]

Au contraire (speaking only for myself).

On Wednesday, February 3, 2010, Eran Hammer-Lahav  wrote:
> It doesn't feel like we have much interest at this level of interoperability 
> at this point.
>
> EHL
>
>> -Original Message-
>> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
>> Sent: Wednesday, February 03, 2010 5:38 AM
>> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
>> authentication challenge?
>>
>> An authentication challenge (WWW-Authenticate header) defined in a spec
>> for an authentication mechanism should be present, but only with details
>> specific to that mechanism (eg list of MAC algorithms).
>>
>> I think there should be a totally separate WWW-Authenticate header
>> specifically saying "a delegation flow can be used to access this resource". 
>> It
>> should include details such as the URI to redirect the user to.
>>
>> We really need this if we want to offer a web-style protocol with any
>> semblance of interoperability. If we omit it because "clients need to know
>> lots of other API-specific details anyway" then we wont have a path to get
>> past that limitation in future.
>>
>>
>> --
>> James Manger
>>
>> > -Original Message-
>> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> > Of Eran Hammer-Lahav
>> > Sent: Thursday, 28 January 2010 2:12 PM
>> > To: OAuth WG (oauth@ietf.org)
>> > Subject: [OAUTH-WG] What are the primary criteria in issuing an
>> > authentication challenge?
>> >
>> > An authentication challenge (to make sure we are all on the same page)
>> > is something the server sends to the client when denying access to a
>> > protected resource. The challenge can be as simple as "use Basic", or
>> > complex as "use Digest with the following parameters". OAuth 1.0
>> > doesn't really use a challenge because it was created for cases where
>> > the API calls are preconfigured and hardcoded into the client. The
>> > client should never receive an OAuth challenge the way the protocol
>> > was originally designed.
>> >
>> > In my token authentication draft I tried to propose multiple
>> > mechanisms (not fully baked yet) for issuing a challenge and allowing
>> > the client to figure out what to do next. Before producing another
>> > draft, it is important to figure out what challenge model we want to
>> > use. Here are the general options I came up with:
>> >
>> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
>> > left on its own to figure out what to do next.
>> >
>> > 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
>> > need a new token go there". It is still not clear how this will help
>> > the client given that getting a token is likely it include many
>> > different options, and to fully address this we need to dig deep into
>> > discovery which was left out of scope.
>> >
>> > 3. Token attributes - the server informs the client of the kind of
>> > tokens accepted (based on their cryptographic properties or the
>> > resource-set/realm they are good for). This is just like #2 but with
>> > the ability for the server to support more than one token type per
>> > resource.
>> >
>> > Question: Is the ability for a single token-protected resource to
>> > support more than one token type (say Plain+SSL *and* HMAC-256) part
>> > of our requirements? If not, there is no reason at all for the
>> > challenge to include anything other than #1 or #2 (probably defined as
>> > a future extension).
>> >
>> > EHL
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> ht 

-- 
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01

[Eran Hammer-Lahav]

Thanks James.

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Wednesday, February 03, 2010 5:03 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01
> 
> Comments on draft-hammer-http-token-auth-01 (3 Feb 2010) after a quick
> read.
> [http://tools.ietf.org/html/draft-hammer-http-token-auth-01]
> 
> The simple bearer token mode is still buried as an exception to the request
> signing rules.

This draft was just to remove the confusing bits. I am still working on it to 
make the plain method easier to notice.

> This just isn’t necessary, it’s awful.

Constructive criticism is always helpful. :-)

> Choosing a hash algorithm is assumed to be done when a credential is issued.
> It is nice crypto-hygiene to only use a given secret with a single algorithm, 
> but
> it is not always sensible. One app may only support SHA-1, while another only
> supports SHA-256. Standard APIs may only accept an id and secret, and
> assume that acceptable hash algorithms are configured elsewhere in the
> software. Having to reissue all credentials to stop supporting an old hash
> algorithm will not always be practical, and looks like a substantial barrier 
> to
> removing support for algorithms that get broken.

I disagree. Voiding a token to stop supporting an algorithm is perfectly 
reasonable and might not even require user involvement if the refresh mechanism 
is (adopted and) used. And if the reason for this is a broken algorithm, well, 
I would hope the tokens are voided, not just used with the same secret and new 
algorithm.

I am not sure what you mean by "one app may only support SHA-1, while another 
only supports SHA-256". Are you suggesting something like a company with 
centralized token service but where each service using a different set of 
algorithm, but still sharing the same token across services? Sounds like a 
company in need of new management.

> I would prefer to stick with more common practise: explicitly list the MAC
> algorithm in a signed request; and support some algorithm negotiation when
> accessing a protected resource (eg by the server listing supported algorithms
> in a WWW-Authenticate header). This doesn’t stop a credential-issuer stating
> that only a specific hash alg can be used with a specific secret, it just 
> doesn’t
> force this mode.

This change was based directly on WG feedback. I asked two questions:

1. What should be included in the challenge?
2. Should one token be allowed to support multiple algorithms?

It seems to me that were was no interest in negotiating algorithms or tokens 
with multiple methods. But I am happy to ask these questions again and see if 
people have different answers now that there is a new draft to poke at.

> There is only a spot for a single id in the protocol, not spots for separate
> authentication and authorization ids. The absence of both in existing
> authentication mechanisms is the only reason there is any concern about
> using those mechanisms with credentials from delegation.

That's another area where I feel there is no interest. The existing schemes 
come with too much existing deployment and expectations - that's why we are not 
reusing them. The token scheme is designed to always work with a server issuing 
tokens, even if there is no end-user. The idea of using it as a replacement for 
Basic auth is pretty much dead considering that requiring servers to keep plain 
text copies of passwords is a deal breaker.

Did you reach a different conclusion from these discussions?

> The example use a poor choice of realm: realm=”http://example.com/”.
> Realms are only meaningful in the scope of the current server. The example
> suggests any-old-site.com can return realm=”http://yahoo.com/” and the
> client will retry the request a set of token credentials issued for Yahoo
> services.

Yeah. I had "Example Resources" before but changed it. The realm parameter 
needs a lot of work.

> Yikes!

Sorry. Didn't mean to scare you.

> The 1st paragraph of the introduction confuses the “client” terminology.
> “Client” is used to means an OAuth “resource owner” and OAuth “client”.

Fixed.

> Breaking the existing model of HTTP authentication (1 scheme per
> mechanism) is the wrong approach.

Not sure what you mean.

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

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[Joseph Anthony Pasquale Holsten]

Please consider my position retracted.
--
j

On Feb 3, 2010, at 8:16 PM, Eran Hammer-Lahav wrote:

> You are going too far. I meant the people on this list. That's the only group 
> that matters.
> 
> EHL
> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Joseph Anthony Pasquale Holsten
>> Sent: Wednesday, February 03, 2010 6:12 PM
>> To: OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
>> authentication challenge?
>> 
>> A self fulfilling prophecy.
>> 
>> Who isn't interested? Client authors or service providers with an incentive 
>> to
>> lock people in? If you work at microsoft or google or yahoo or facebook, you
>> might consider asking people like ping.fm how much they care about
>> interoperability. And maybe ask why the people who are supposed to be
>> consuming these services aren't active on these lists.
>> --
>> j
>> 
>> On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote:
>> 
>>> It doesn't feel like we have much interest at this level of 
>>> interoperability at
>> this point.
>>> 
>>> EHL
>>> 
 -Original Message-
 From: Manger, James H [mailto:james.h.man...@team.telstra.com]
 Sent: Wednesday, February 03, 2010 5:38 AM
 To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
 Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
 authentication challenge?
 
 An authentication challenge (WWW-Authenticate header) defined in a
 spec for an authentication mechanism should be present, but only with
 details specific to that mechanism (eg list of MAC algorithms).
 
 I think there should be a totally separate WWW-Authenticate header
 specifically saying "a delegation flow can be used to access this
 resource". It should include details such as the URI to redirect the user 
 to.
 
 We really need this if we want to offer a web-style protocol with any
 semblance of interoperability. If we omit it because "clients need to
 know lots of other API-specific details anyway" then we wont have a
 path to get past that limitation in future.
 
 
 --
 James Manger
 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> Behalf Of Eran Hammer-Lahav
> Sent: Thursday, 28 January 2010 2:12 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> An authentication challenge (to make sure we are all on the same
> page) is something the server sends to the client when denying
> access to a protected resource. The challenge can be as simple as
> "use Basic", or complex as "use Digest with the following
> parameters". OAuth 1.0 doesn't really use a challenge because it was
> created for cases where the API calls are preconfigured and
> hardcoded into the client. The client should never receive an OAuth
> challenge the way the protocol was originally designed.
> 
> In my token authentication draft I tried to propose multiple
> mechanisms (not fully baked yet) for issuing a challenge and
> allowing the client to figure out what to do next. Before producing
> another draft, it is important to figure out what challenge model we
> want to use. Here are the general options I came up with:
> 
> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
> left on its own to figure out what to do next.
> 
> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> need a new token go there". It is still not clear how this will help
> the client given that getting a token is likely it include many
> different options, and to fully address this we need to dig deep
> into discovery which was left out of scope.
> 
> 3. Token attributes - the server informs the client of the kind of
> tokens accepted (based on their cryptographic properties or the
> resource-set/realm they are good for). This is just like #2 but with
> the ability for the server to support more than one token type per
> resource.
> 
> Question: Is the ability for a single token-protected resource to
> support more than one token type (say Plain+SSL *and* HMAC-256) part
> of our requirements? If not, there is no reason at all for the
> challenge to include anything other than #1 or #2 (probably defined
> as a future extension).
> 
> EHL
> 
> ___
> 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 mailing list
>> OAuth@ietf.org
>> https://

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[Eran Hammer-Lahav]

You are going too far. I meant the people on this list. That's the only group 
that matters.

EHL

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Joseph Anthony Pasquale Holsten
> Sent: Wednesday, February 03, 2010 6:12 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> A self fulfilling prophecy.
> 
> Who isn't interested? Client authors or service providers with an incentive to
> lock people in? If you work at microsoft or google or yahoo or facebook, you
> might consider asking people like ping.fm how much they care about
> interoperability. And maybe ask why the people who are supposed to be
> consuming these services aren't active on these lists.
> --
> j
> 
> On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote:
> 
> > It doesn't feel like we have much interest at this level of 
> > interoperability at
> this point.
> >
> > EHL
> >
> >> -Original Message-
> >> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> >> Sent: Wednesday, February 03, 2010 5:38 AM
> >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
> >> authentication challenge?
> >>
> >> An authentication challenge (WWW-Authenticate header) defined in a
> >> spec for an authentication mechanism should be present, but only with
> >> details specific to that mechanism (eg list of MAC algorithms).
> >>
> >> I think there should be a totally separate WWW-Authenticate header
> >> specifically saying "a delegation flow can be used to access this
> >> resource". It should include details such as the URI to redirect the user 
> >> to.
> >>
> >> We really need this if we want to offer a web-style protocol with any
> >> semblance of interoperability. If we omit it because "clients need to
> >> know lots of other API-specific details anyway" then we wont have a
> >> path to get past that limitation in future.
> >>
> >>
> >> --
> >> James Manger
> >>
> >>> -Original Message-
> >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >>> Behalf Of Eran Hammer-Lahav
> >>> Sent: Thursday, 28 January 2010 2:12 PM
> >>> To: OAuth WG (oauth@ietf.org)
> >>> Subject: [OAUTH-WG] What are the primary criteria in issuing an
> >>> authentication challenge?
> >>>
> >>> An authentication challenge (to make sure we are all on the same
> >>> page) is something the server sends to the client when denying
> >>> access to a protected resource. The challenge can be as simple as
> >>> "use Basic", or complex as "use Digest with the following
> >>> parameters". OAuth 1.0 doesn't really use a challenge because it was
> >>> created for cases where the API calls are preconfigured and
> >>> hardcoded into the client. The client should never receive an OAuth
> >>> challenge the way the protocol was originally designed.
> >>>
> >>> In my token authentication draft I tried to propose multiple
> >>> mechanisms (not fully baked yet) for issuing a challenge and
> >>> allowing the client to figure out what to do next. Before producing
> >>> another draft, it is important to figure out what challenge model we
> >>> want to use. Here are the general options I came up with:
> >>>
> >>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
> >>> left on its own to figure out what to do next.
> >>>
> >>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> >>> need a new token go there". It is still not clear how this will help
> >>> the client given that getting a token is likely it include many
> >>> different options, and to fully address this we need to dig deep
> >>> into discovery which was left out of scope.
> >>>
> >>> 3. Token attributes - the server informs the client of the kind of
> >>> tokens accepted (based on their cryptographic properties or the
> >>> resource-set/realm they are good for). This is just like #2 but with
> >>> the ability for the server to support more than one token type per
> >>> resource.
> >>>
> >>> Question: Is the ability for a single token-protected resource to
> >>> support more than one token type (say Plain+SSL *and* HMAC-256) part
> >>> of our requirements? If not, there is no reason at all for the
> >>> challenge to include anything other than #1 or #2 (probably defined
> >>> as a future extension).
> >>>
> >>> EHL
> >>>
> >>> ___
> >>> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[Joseph Anthony Pasquale Holsten]

A self fulfilling prophecy.

Who isn't interested? Client authors or service providers with an incentive to 
lock people in? If you work at microsoft or google or yahoo or facebook, you 
might consider asking people like ping.fm how much they care about 
interoperability. And maybe ask why the people who are supposed to be consuming 
these services aren't active on these lists.
--
j

On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote:

> It doesn't feel like we have much interest at this level of interoperability 
> at this point.
> 
> EHL
> 
>> -Original Message-
>> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
>> Sent: Wednesday, February 03, 2010 5:38 AM
>> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
>> authentication challenge?
>> 
>> An authentication challenge (WWW-Authenticate header) defined in a spec
>> for an authentication mechanism should be present, but only with details
>> specific to that mechanism (eg list of MAC algorithms).
>> 
>> I think there should be a totally separate WWW-Authenticate header
>> specifically saying "a delegation flow can be used to access this resource". 
>> It
>> should include details such as the URI to redirect the user to.
>> 
>> We really need this if we want to offer a web-style protocol with any
>> semblance of interoperability. If we omit it because "clients need to know
>> lots of other API-specific details anyway" then we wont have a path to get
>> past that limitation in future.
>> 
>> 
>> --
>> James Manger
>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>>> Of Eran Hammer-Lahav
>>> Sent: Thursday, 28 January 2010 2:12 PM
>>> To: OAuth WG (oauth@ietf.org)
>>> Subject: [OAUTH-WG] What are the primary criteria in issuing an
>>> authentication challenge?
>>> 
>>> An authentication challenge (to make sure we are all on the same page)
>>> is something the server sends to the client when denying access to a
>>> protected resource. The challenge can be as simple as "use Basic", or
>>> complex as "use Digest with the following parameters". OAuth 1.0
>>> doesn't really use a challenge because it was created for cases where
>>> the API calls are preconfigured and hardcoded into the client. The
>>> client should never receive an OAuth challenge the way the protocol
>>> was originally designed.
>>> 
>>> In my token authentication draft I tried to propose multiple
>>> mechanisms (not fully baked yet) for issuing a challenge and allowing
>>> the client to figure out what to do next. Before producing another
>>> draft, it is important to figure out what challenge model we want to
>>> use. Here are the general options I came up with:
>>> 
>>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
>>> left on its own to figure out what to do next.
>>> 
>>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
>>> need a new token go there". It is still not clear how this will help
>>> the client given that getting a token is likely it include many
>>> different options, and to fully address this we need to dig deep into
>>> discovery which was left out of scope.
>>> 
>>> 3. Token attributes - the server informs the client of the kind of
>>> tokens accepted (based on their cryptographic properties or the
>>> resource-set/realm they are good for). This is just like #2 but with
>>> the ability for the server to support more than one token type per
>>> resource.
>>> 
>>> Question: Is the ability for a single token-protected resource to
>>> support more than one token type (say Plain+SSL *and* HMAC-256) part
>>> of our requirements? If not, there is no reason at all for the
>>> challenge to include anything other than #1 or #2 (probably defined as
>>> a future extension).
>>> 
>>> EHL
>>> 
>>> ___
>>> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Comment on draft-hammer-http-token-auth-01

[Manger, James H]

Comments on draft-hammer-http-token-auth-01 (3 Feb 2010) after a quick read.

[http://tools.ietf.org/html/draft-hammer-http-token-auth-01]



The simple bearer token mode is still buried as an exception to the request 
signing rules. This just isn’t necessary, it’s awful.



Choosing a hash algorithm is assumed to be done when a credential is issued. It 
is nice crypto-hygiene to only use a given secret with a single algorithm, but 
it is not always sensible. One app may only support SHA-1, while another only 
supports SHA-256. Standard APIs may only accept an id and secret, and assume 
that acceptable hash algorithms are configured elsewhere in the software. 
Having to reissue all credentials to stop supporting an old hash algorithm will 
not always be practical, and looks like a substantial barrier to removing 
support for algorithms that get broken.



I would prefer to stick with more common practise: explicitly list the MAC 
algorithm in a signed request; and support some algorithm negotiation when 
accessing a protected resource (eg by the server listing supported algorithms 
in a WWW-Authenticate header). This doesn’t stop a credential-issuer stating 
that only a specific hash alg can be used with a specific secret, it just 
doesn’t force this mode.



There is only a spot for a single id in the protocol, not spots for separate 
authentication and authorization ids. The absence of both in existing 
authentication mechanisms is the only reason there is any concern about using 
those mechanisms with credentials from delegation.



The example use a poor choice of realm: realm=”http://example.com/”. Realms are 
only meaningful in the scope of the current server. The example suggests 
any-old-site.com can return realm=”http://yahoo.com/” and the client will retry 
the request a set of token credentials issued for Yahoo services. Yikes!



The 1st paragraph of the introduction confuses the “client” terminology. 
“Client” is used to means an OAuth “resource owner” and OAuth “client”.



Breaking the existing model of HTTP authentication (1 scheme per mechanism) is 
the wrong approach.



--

James Manger



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

Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Eran Hammer-Lahav]

> -Original Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Wednesday, February 03, 2010 3:23 PM
> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: RE: Token Access Authentication Scheme Draft
> 
> > The reason why it makes little sense to have different schemes for
> > different types of tokens is that it is not the protected resource's
> > job to say which algorithm should be used, but the server when issuing
> > the token for that resource. The draft did a poor job at separating
> > the role of the server issuing the tokens from the role of the server
> > providing access to resources.
> 
> 
> It is not the role of a spec for an HTTP authentication mechanism to make
> assumptions about how credentials are issued, or assumptions about what
> additional authentication mechanisms might be supported by any particular
> server.

It doesn't.

> I am very happy for a security server to say:
>   eg "use this token+secret with HMAC-SHA256 at http://api.example.org/
> for 10 minutes"
> A security server may want to be a little less specific:
>   eg "use this token+secret with any MAC algorithm at
> http://*.example.com/";
> Or
>   eg "use this token+secret with the OAuth MAC algs or draft-oiwa-http-
> mutualauth at xyz".

This is exactly what the current draft proposes, as long as these statements 
are "said" by the server when issuing the credentials, not when sending a 401 
response.

All the spec is doing in that regard is giving these statements a common 
language to enable interop for a few methods.
 
EHL

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

Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Manger, James H]

> The reason why it makes little sense to have different schemes for
> different types of tokens is that it is not the protected resource's
> job to say which algorithm should be used, but the server when issuing
> the token for that resource. The draft did a poor job at separating the
> role of the server issuing the tokens from the role of the server
> providing access to resources.


It is not the role of a spec for an HTTP authentication mechanism to make 
assumptions about how credentials are issued, or assumptions about what 
additional authentication mechanisms might be supported by any particular 
server. I hope a HTTP request-signing spec does not need to assume that a 
separate security server is involved to do all possible mechanism negotiation.


I am very happy for a security server to say:
  eg "use this token+secret with HMAC-SHA256 at http://api.example.org/ for 10 
minutes"
A security server may want to be a little less specific:
  eg "use this token+secret with any MAC algorithm at http://*.example.com/";
Or
  eg "use this token+secret with the OAuth MAC algs or 
draft-oiwa-http-mutualauth at xyz".

A statement from a security server binding a token+secret to
  "1 or more 'mechanisms' of the 'Token' scheme"
is no easier than a statement binding then to
  "1 or more 'schemes'",
Binding to 'mechanisms' of the 'Token' scheme is significantly worse as it 
exclude a whole swag of current and future authentication mechanisms that are 
not written with OAuth specifically in mind.


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

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote:

> 
> 
> On 2/3/10 12:46 PM, Dick Hardt wrote:
> 
>> Wanting to discuss technical details when there does not seem to be
>> consensus on the problem we are solving was my Titanic reference.
> 
>  Remember, these interim meetings are
> intended to air open issues and get us closer to agreement on problems,
> terminology, architecture, use cases, requirements, and possible
> technical solutions, all as a way of preparing for the in-person meeting
> in Anaheim.

That was what I thought the calls were for, which is why I did not think Eran's 
desire to add discussion of a specific technical issue was going to be well 
received. There are a number of us that are new to the WG and we likely will 
make little progress until we are all relatively on the same page on what 
problem(s) we are solving. I certainly hope we don't need to spend much time on 
these topics, but some time will be invaluable in my opinion.

Speaking for myself, I am still confused why the spec has been broken into two 
parts and what is intended in the Authentication document. I am just now 
starting to try and grok what the UMA people want to solve.

-- Dick

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

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Peter Saint-Andre]

On 2/3/10 12:46 PM, Dick Hardt wrote:

> Wanting to discuss technical details when there does not seem to be
> consensus on the problem we are solving was my Titanic reference.

We have two dangers here:

1. The Scylla of designing technologies before we fully understand the
problem space and its associated requirements.

2. The Charybdis of discussing the problem space and its associated
requirements but never designing any technologies.

We are attempting to steer a safe course between these two dangers.
Although I tend to the side of those who fear Scylla more than
Charybdis, in my opinion (not consensus that I am declaring as co-chair)
we have enough sense of the problem space regarding authentication that
we can at least have a productive discussion about
draft-ietf-oauth-authentication-01 at tomorrow's interim meeting.
However, in parallel I think we need to keep sifting through various use
cases, and Blaine's stub of a feature matrix is a good first step that
needs more attention before the interim meeting we'll hold two weeks
from tomorrow (February 18). Remember, these interim meetings are
intended to air open issues and get us closer to agreement on problems,
terminology, architecture, use cases, requirements, and possible
technical solutions, all as a way of preparing for the in-person meeting
in Anaheim. IMHO we need to keep working in several directions at once,
so let's keep building out our wiki pages and updating the relevant
Internet-Drafts and sifting through use cases and working through open
issues on this list. Perhaps that's not a perfect process, but I think
it's the best we can do for now. If you disagree, feel free to do so on
list or off. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 11:21 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, February 03, 2010 11:19 AM
>> To: Dick Hardt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> I did not mean my first reply to you to be abrasive or confrontational
> 
> INSERT: and I apologize if it came off that way.

Thanks. All good on my side.

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

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 11:19 AM, Eran Hammer-Lahav wrote:

> I did not mean my first reply to you to be abrasive or confrontational, 
> despite being told that my work on the drafts is a waste of time ("moving 
> around deck chairs on the Titanic").

I and many others appreciate your work. That was not my intent. Wanting to 
discuss technical details when there does not seem to be consensus on the 
problem we are solving was my Titanic reference.

> 
> Any consensus call must be made on the list and not just on the call or in a 
> meeting because the list is the only place everyone is guaranteed equal 
> participation. There is nothing more important in the IETF process than 
> consensus calls and I take them very seriously.

Thanks for the clarification.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Eran Hammer-Lahav]

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, February 03, 2010 11:19 AM
> To: Dick Hardt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> I did not mean my first reply to you to be abrasive or confrontational

INSERT: and I apologize if it came off that way.

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

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Eran Hammer-Lahav]

I did not mean my first reply to you to be abrasive or confrontational, despite 
being told that my work on the drafts is a waste of time ("moving around deck 
chairs on the Titanic"). I simply disagreed with your view that it is too early 
to dedicate the next call to technical details. I actually took the time to 
articulate an alternative way of moving forward that is more consistent with my 
experience here for the past year.

It was your later comments (educating me about what took place on that call, 
which assumed I didn't bother to read the minutes or listen to the audio) that 
I didn't appreciate.

Any consensus call must be made on the list and not just on the call or in a 
meeting because the list is the only place everyone is guaranteed equal 
participation. There is nothing more important in the IETF process than 
consensus calls and I take them very seriously.

EHL

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Wednesday, February 03, 2010 10:55 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> I recall from the call that Peter did ask if there was consensus on the
> approach of gathering use cases. There seemed consensus that the WG
> might not fully understand the problem and that this made sense. I don't see
> that clearly captured in the minutes, hence me communicating to you what
> had occurred on the call.
> 
> FWIW: II had intended my email to be useful, non-confrontational feedback
> on your agenda proposal. I am finding your responses to be abrasive. Have I
> offended you in some way? If you have suggestions for what I can do to be
> more productive in communicating to you, I would welcome them.
> 
> -- Dick
> 
> 
> On 2010-02-03, at 9:59 AM, Eran Hammer-Lahav wrote:
> 
> > I read the minutes.
> >
> > I don't need to be on the call to present my views on how to proceed.
> That's not how the IETF operates. I have been expressing my views for the
> past year, right here on the list. I didn't see any consensus call from the 
> chairs
> about taking this approach (instead of others).
> >
> > I also noticed the lack of follow up since the call with any kind of 
> > discussion
> on use cases.
> >
> > I have asked the chairs to provide a place to discuss technical issues and
> that is what this second call is about. Unless the chairs decide to change it.
> >
> > EHL
> >
> >> -Original Message-
> >> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> >> Sent: Wednesday, February 03, 2010 9:43 AM
> >> To: Eran Hammer-Lahav
> >> Cc: Anthony Nadalin; OAuth WG
> >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> Eran,
> >>
> >> Both Tony and I are explaining to you what happened on the call. If
> >> you had been on the call, you could have presented your view on how
> >> to proceed with the calls.
> >> While you may have a different opinion on how to proceed (which I am
> >> NOT arguing with), arguing with us on what happened on the call seems
> pointless.
> >>
> >> -- Dick
> >>
> >> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
> >>
> >>> Hi Anthony,
> >>>
> >>> The problem with this approach is that it hasn't worked (multiple
> >>> times)
> >> before because no one ever wants to do the work of collecting and
> >> writing the use cases. What we get instead are short cryptic lists
> >> and pointers to edge cases. We have a good grasp on how OAuth 1.0 is
> >> used and its limitations as addressed by the WRAP draft.
> >>>
> >>> The best use of my time is to continue working on the drafts and
> >>> asking
> >> technical questions whenever a decision is needed. If and when
> >> someone writes use cases, I will review those and see if they are
> >> supported by the drafts.
> >>>
> >>> I will leave it up to the chairs to decide how they want to guide
> >>> the working
> >> group.
> >>>
> >>> EHL
> >>>
>  -Original Message-
>  From: Anthony Nadalin [mailto:tony...@microsoft.com]
>  Sent: Wednesday, February 03, 2010 9:02 AM
>  To: Eran Hammer-Lahav; Dick Hardt
>  Cc: OAuth WG
>  Subject: RE: [OAUTH-WG] proposed agenda for second interim
> meeting
> 
>  I would tend to agree with Dick based upon the last call and where
>  that was heading. I believe that Eve had some use cases to share
>  around UMA
> 
>  -Original Message-
>  From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
>  Behalf Of Eran Hammer-Lahav
>  Sent: Wednesday, February 03, 2010 8:41 AM
>  To: Dick Hardt
>  Cc: OAuth WG
>  Subject: Re: [OAUTH-WG] proposed agenda for second interim
> meeting
> 
>  Has anyone gathered and reviewed use cases? I haven't seen much of
>  that showing up on the list. From my experience, asking people for
>  use cases rarely works, unless someone is willing to do the work
>  and collect them (and so far I haven't heard from such volunteer).
>  I 

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

I recall from the call that Peter did ask if there was consensus on the 
approach of gathering use cases. There seemed consensus that the WG might not 
fully understand the problem and that this made sense. I don't see that clearly 
captured in the minutes, hence me communicating to you what had occurred on the 
call. 

FWIW: II had intended my email to be useful, non-confrontational feedback on 
your agenda proposal. I am finding your responses to be abrasive. Have I 
offended you in some way? If you have suggestions for what I can do to be more 
productive in communicating to you, I would welcome them.

-- Dick


On 2010-02-03, at 9:59 AM, Eran Hammer-Lahav wrote:

> I read the minutes.
> 
> I don't need to be on the call to present my views on how to proceed. That's 
> not how the IETF operates. I have been expressing my views for the past year, 
> right here on the list. I didn't see any consensus call from the chairs about 
> taking this approach (instead of others).
> 
> I also noticed the lack of follow up since the call with any kind of 
> discussion on use cases.
> 
> I have asked the chairs to provide a place to discuss technical issues and 
> that is what this second call is about. Unless the chairs decide to change it.
> 
> EHL
> 
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Wednesday, February 03, 2010 9:43 AM
>> To: Eran Hammer-Lahav
>> Cc: Anthony Nadalin; OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> Eran,
>> 
>> Both Tony and I are explaining to you what happened on the call. If you had
>> been on the call, you could have presented your view on how to proceed
>> with the calls.
>> While you may have a different opinion on how to proceed (which I am NOT
>> arguing with), arguing with us on what happened on the call seems pointless.
>> 
>> -- Dick
>> 
>> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
>> 
>>> Hi Anthony,
>>> 
>>> The problem with this approach is that it hasn't worked (multiple times)
>> before because no one ever wants to do the work of collecting and writing
>> the use cases. What we get instead are short cryptic lists and pointers to
>> edge cases. We have a good grasp on how OAuth 1.0 is used and its
>> limitations as addressed by the WRAP draft.
>>> 
>>> The best use of my time is to continue working on the drafts and asking
>> technical questions whenever a decision is needed. If and when someone
>> writes use cases, I will review those and see if they are supported by the
>> drafts.
>>> 
>>> I will leave it up to the chairs to decide how they want to guide the 
>>> working
>> group.
>>> 
>>> EHL
>>> 
 -Original Message-
 From: Anthony Nadalin [mailto:tony...@microsoft.com]
 Sent: Wednesday, February 03, 2010 9:02 AM
 To: Eran Hammer-Lahav; Dick Hardt
 Cc: OAuth WG
 Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
 
 I would tend to agree with Dick based upon the last call and where
 that was heading. I believe that Eve had some use cases to share
 around UMA
 
 -Original Message-
 From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
 Behalf Of Eran Hammer-Lahav
 Sent: Wednesday, February 03, 2010 8:41 AM
 To: Dick Hardt
 Cc: OAuth WG
 Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
 
 Has anyone gathered and reviewed use cases? I haven't seen much of
 that showing up on the list. From my experience, asking people for
 use cases rarely works, unless someone is willing to do the work and
 collect them (and so far I haven't heard from such volunteer). I much
 prefer the process in which we produce a technical document based on
 OAuth 1.0 and the new requirements as defined by WRAP, and discuss
 use cases as a property of the technical attributes of this draft.
 
 Of course, you don't have to agree with me, but that puts the burden
 of producing use cases documentation on you and others interested in
 taking that approach. We certainly have room for both, and keep in
 mind that my token draft is not (yet) a working group item.
 
 The indication I received from many of the active members of this
 list is that we have a strong desire to show up at Anaheim with two
 stable drafts. I think we are very close to getting the
 authentication piece done following much of OAuth 1.0 functionality
 (only cleaner and better structures), as well as treating bearer
 tokens as first class citizens. Given that no one has started a
 discussion about the delegation flows to include, I doubt we will
 have a stable second draft, but I plan on getting the authentication piece
>> stable in time.
 
 It has also been my experience over the past two years that the
 biggest challenge is to figure out the authentication piece. The 'go
 get a token' piece tends to be much easier

[OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting)

[Eve Maler]

Sorry for the delay, and thanks for the push.  In scrambling to approve a 
passel of scenarios and produce our webinar last week, we got a bit behind.  
(By the way, complete recordings are now available.  Their quality is not 
perfect, but should suffice.  Please see 
http://kantarainitiative.org/confluence/display/uma/UMA+Explained for 
recordings, overview slides, protocol explanation slides, and example 
wireframes.)

In order to inform the OAuth V2.0 effort, here is some information about key 
User-Managed Access (UMA) use cases and needs.  The wiki home is at 
http://kantarainitiative.org/confluence/display/uma/Home , and the sidebar on 
the right has links to all the available materials.

The focus of UMA is to externalize authorization decisions currently performed 
by OAuth SPs/servers into a fourth distinct entity we call an "authorization 
manager" or AM.  Protected resources are hosted at endpoints called "hosts" and 
the endpoints seeking data/service access are called "requesters". An 
application embodying the AM endpoint can help the "authorizing user" globally 
manage what otherwise might be a complicated authorization picture among all 
the services accessing and sharing data about her, including letting her 
dictate policies for access authorization that the AM enforces.  (If you're 
familiar with classic access management technology, the AM serves as a policy 
decision point and the hosts are policy enforcement points.)  An AM provides 
the user with the ability to apply discretionary access controls for his/her 
resources. 

The extensive information available about UMA includes a Scenarios and Use 
Cases document:

http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases

Here are summaries of two of the group's approved scenarios.

Calendaring: Online calendars, whose content is volatile, are valuable to share 
on an ongoing/"feed" basis.  In somewhat the same fashion that people today 
share online calendars selectively with other people, a user can share a 
calendar with a vendor for various purposes.  Prior to allowing the access, she 
might use UMA to require the requester to assure her they will not misuse or 
further share her information.  Having authorized access to a particular 
resource, the user can then examine all the connections forged to all her 
shared resources in similar fashion, from a single console.

Personal Loan: A user applies for a loan online, and the loan application site 
requires him to provide certain third-party-attested information, such as his 
salary, bank account, and credit score.  This information is best hosted 
directly out of the (several) authoritative sites for it, but the user is able 
to package up references to all of it and point the loan site to the package; 
the loan site can then become a requester of each relevant resource.  The user 
can see, from a single place, whether the information has been successfully 
received, and can keep a record of its access.  (The webinar wireframes show 
how this packaging might be achieved, along with illustrating other potential 
parts of the user experience.)

UMA currently solves its use cases, in part, with a composition of three 
instances of OAuth (along with using XRD metadata and LRDD discovery methods).  
The user introduces each host to the AM with so-called "three-legged" (authn 
plus web delegation) OAuth as a preface to other interactions.  Each requester 
later dynamically introduces itself to a host with the option of using 
"two-legged" (authn only) OAuth, and then introduces itself to the AM using 
two-legged OAuth -- we think of these as "automated self-registration" of the 
services.  The draft spec can be found here:

http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

A few key points:

- UMA wants to give users an opportunity, not just to set unilateral policy 
(how long access is allowed over time, whether the user should be asked for 
real-time consent in some fashion when access is attempted, and so on), but 
also to set terms which the requester must meet. This gives users new tools for 
control, and also enables some interesting high-value use cases, involving 
requests for access on the basis of third-party-attested claims.

- There is a conceptual similarity between the UMA and WRAP entities, but our 
analysis so far shows it to be shallow in spots.  For example, WRAP's 
"protected resource" maps fairly well to an UMA "host" (which may host any 
number of protected resources), and WRAP's and OAuth's "client"/"consumer" maps 
to an UMA "requester".  However, it seems that a WRAP authorization server is 
assumed to be in the same domain as a protected resource, allowing for implicit 
rather than explicit scoping of resources.  The UMA authorization manager and 
any one host may be in entirely separate domains, and introductions between 
them are intended to be user-driven.

Eve

On 3 Feb 2010, at 9:34 AM, Eran Hammer-Laha

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Blaine Cook]

I've started a wiki page here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix

to pull in the features people think are important, and give us both
some way of collecting that data over time and expressing what's
present or missing from each protocol & proposal. Despite being called
FeatureMatrix, please treat it as a Use Case Matrix.

If people don't want to go in and edit the wiki table (I don't blame
you) please send your use cases to me (rom...@gmail.com) and I will
fill them out on the wiki for you. If you have blog posts or links to
pre-existing use cases or features, please include those as they will
help clarify the features.

b.

ps. the wiki won't let me put in a bookmarklet to make the text entry
not suck (i.e., use a fixed-width font), so here's one in case you do
decide to edit the wiki:

javascript:document.getElementById('text').style.fontFamily='courier'

On 3 February 2010 17:59, Eran Hammer-Lahav  wrote:
> I read the minutes.
>
> I don't need to be on the call to present my views on how to proceed. That's 
> not how the IETF operates. I have been expressing my views for the past year, 
> right here on the list. I didn't see any consensus call from the chairs about 
> taking this approach (instead of others).
>
> I also noticed the lack of follow up since the call with any kind of 
> discussion on use cases.
>
> I have asked the chairs to provide a place to discuss technical issues and 
> that is what this second call is about. Unless the chairs decide to change it.
>
> EHL
>
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Wednesday, February 03, 2010 9:43 AM
>> To: Eran Hammer-Lahav
>> Cc: Anthony Nadalin; OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>>
>> Eran,
>>
>> Both Tony and I are explaining to you what happened on the call. If you had
>> been on the call, you could have presented your view on how to proceed
>> with the calls.
>> While you may have a different opinion on how to proceed (which I am NOT
>> arguing with), arguing with us on what happened on the call seems pointless.
>>
>> -- Dick
>>
>> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
>>
>> > Hi Anthony,
>> >
>> > The problem with this approach is that it hasn't worked (multiple times)
>> before because no one ever wants to do the work of collecting and writing
>> the use cases. What we get instead are short cryptic lists and pointers to
>> edge cases. We have a good grasp on how OAuth 1.0 is used and its
>> limitations as addressed by the WRAP draft.
>> >
>> > The best use of my time is to continue working on the drafts and asking
>> technical questions whenever a decision is needed. If and when someone
>> writes use cases, I will review those and see if they are supported by the
>> drafts.
>> >
>> > I will leave it up to the chairs to decide how they want to guide the 
>> > working
>> group.
>> >
>> > EHL
>> >
>> >> -Original Message-
>> >> From: Anthony Nadalin [mailto:tony...@microsoft.com]
>> >> Sent: Wednesday, February 03, 2010 9:02 AM
>> >> To: Eran Hammer-Lahav; Dick Hardt
>> >> Cc: OAuth WG
>> >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>> >>
>> >> I would tend to agree with Dick based upon the last call and where
>> >> that was heading. I believe that Eve had some use cases to share
>> >> around UMA
>> >>
>> >> -Original Message-
>> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
>> >> Behalf Of Eran Hammer-Lahav
>> >> Sent: Wednesday, February 03, 2010 8:41 AM
>> >> To: Dick Hardt
>> >> Cc: OAuth WG
>> >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> >>
>> >> Has anyone gathered and reviewed use cases? I haven't seen much of
>> >> that showing up on the list. From my experience, asking people for
>> >> use cases rarely works, unless someone is willing to do the work and
>> >> collect them (and so far I haven't heard from such volunteer). I much
>> >> prefer the process in which we produce a technical document based on
>> >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss
>> >> use cases as a property of the technical attributes of this draft.
>> >>
>> >> Of course, you don't have to agree with me, but that puts the burden
>> >> of producing use cases documentation on you and others interested in
>> >> taking that approach. We certainly have room for both, and keep in
>> >> mind that my token draft is not (yet) a working group item.
>> >>
>> >> The indication I received from many of the active members of this
>> >> list is that we have a strong desire to show up at Anaheim with two
>> >> stable drafts. I think we are very close to getting the
>> >> authentication piece done following much of OAuth 1.0 functionality
>> >> (only cleaner and better structures), as well as treating bearer
>> >> tokens as first class citizens. Given that no one has started a
>> >> discussion about the delegation flows to include, I d

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Eran Hammer-Lahav]

I read the minutes.

I don't need to be on the call to present my views on how to proceed. That's 
not how the IETF operates. I have been expressing my views for the past year, 
right here on the list. I didn't see any consensus call from the chairs about 
taking this approach (instead of others).

I also noticed the lack of follow up since the call with any kind of discussion 
on use cases.

I have asked the chairs to provide a place to discuss technical issues and that 
is what this second call is about. Unless the chairs decide to change it.

EHL

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Wednesday, February 03, 2010 9:43 AM
> To: Eran Hammer-Lahav
> Cc: Anthony Nadalin; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Eran,
> 
> Both Tony and I are explaining to you what happened on the call. If you had
> been on the call, you could have presented your view on how to proceed
> with the calls.
> While you may have a different opinion on how to proceed (which I am NOT
> arguing with), arguing with us on what happened on the call seems pointless.
> 
> -- Dick
> 
> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
> 
> > Hi Anthony,
> >
> > The problem with this approach is that it hasn't worked (multiple times)
> before because no one ever wants to do the work of collecting and writing
> the use cases. What we get instead are short cryptic lists and pointers to
> edge cases. We have a good grasp on how OAuth 1.0 is used and its
> limitations as addressed by the WRAP draft.
> >
> > The best use of my time is to continue working on the drafts and asking
> technical questions whenever a decision is needed. If and when someone
> writes use cases, I will review those and see if they are supported by the
> drafts.
> >
> > I will leave it up to the chairs to decide how they want to guide the 
> > working
> group.
> >
> > EHL
> >
> >> -Original Message-
> >> From: Anthony Nadalin [mailto:tony...@microsoft.com]
> >> Sent: Wednesday, February 03, 2010 9:02 AM
> >> To: Eran Hammer-Lahav; Dick Hardt
> >> Cc: OAuth WG
> >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> I would tend to agree with Dick based upon the last call and where
> >> that was heading. I believe that Eve had some use cases to share
> >> around UMA
> >>
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of Eran Hammer-Lahav
> >> Sent: Wednesday, February 03, 2010 8:41 AM
> >> To: Dick Hardt
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> Has anyone gathered and reviewed use cases? I haven't seen much of
> >> that showing up on the list. From my experience, asking people for
> >> use cases rarely works, unless someone is willing to do the work and
> >> collect them (and so far I haven't heard from such volunteer). I much
> >> prefer the process in which we produce a technical document based on
> >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss
> >> use cases as a property of the technical attributes of this draft.
> >>
> >> Of course, you don't have to agree with me, but that puts the burden
> >> of producing use cases documentation on you and others interested in
> >> taking that approach. We certainly have room for both, and keep in
> >> mind that my token draft is not (yet) a working group item.
> >>
> >> The indication I received from many of the active members of this
> >> list is that we have a strong desire to show up at Anaheim with two
> >> stable drafts. I think we are very close to getting the
> >> authentication piece done following much of OAuth 1.0 functionality
> >> (only cleaner and better structures), as well as treating bearer
> >> tokens as first class citizens. Given that no one has started a
> >> discussion about the delegation flows to include, I doubt we will
> >> have a stable second draft, but I plan on getting the authentication piece
> stable in time.
> >>
> >> It has also been my experience over the past two years that the
> >> biggest challenge is to figure out the authentication piece. The 'go
> >> get a token' piece tends to be much easier to agree on. If we get the
> >> authentication draft to a stable place, my intention is to leave it
> >> there and focus on the second part and come back to it as the
> >> delegation requirements become clearer (if changes are needed). But at
> least it gives us something stable to build upon.
> >>
> >> EHL
> >>
> >>> -Original Message-
> >>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> >>> Sent: Wednesday, February 03, 2010 7:02 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc: Peter Saint-Andre; OAuth WG
> >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> >>>
> >>> Hi Eran
> >>>
> >>> I think it is a little early in our phone discussions to get into 
> >>> technical
> details.
> >>> The next step according 

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

Eran, 

Both Tony and I are explaining to you what happened on the call. If you had 
been on the call, you could have presented your view on how to proceed with the 
calls. 
While you may have a different opinion on how to proceed (which I am NOT 
arguing with), arguing with us on what happened on the call seems pointless.

-- Dick

On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:

> Hi Anthony,
> 
> The problem with this approach is that it hasn't worked (multiple times) 
> before because no one ever wants to do the work of collecting and writing the 
> use cases. What we get instead are short cryptic lists and pointers to edge 
> cases. We have a good grasp on how OAuth 1.0 is used and its limitations as 
> addressed by the WRAP draft.
> 
> The best use of my time is to continue working on the drafts and asking 
> technical questions whenever a decision is needed. If and when someone writes 
> use cases, I will review those and see if they are supported by the drafts.
> 
> I will leave it up to the chairs to decide how they want to guide the working 
> group.
> 
> EHL
> 
>> -Original Message-
>> From: Anthony Nadalin [mailto:tony...@microsoft.com]
>> Sent: Wednesday, February 03, 2010 9:02 AM
>> To: Eran Hammer-Lahav; Dick Hardt
>> Cc: OAuth WG
>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> I would tend to agree with Dick based upon the last call and where that was
>> heading. I believe that Eve had some use cases to share around UMA
>> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, February 03, 2010 8:41 AM
>> To: Dick Hardt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> Has anyone gathered and reviewed use cases? I haven't seen much of that
>> showing up on the list. From my experience, asking people for use cases
>> rarely works, unless someone is willing to do the work and collect them (and
>> so far I haven't heard from such volunteer). I much prefer the process in
>> which we produce a technical document based on OAuth 1.0 and the new
>> requirements as defined by WRAP, and discuss use cases as a property of the
>> technical attributes of this draft.
>> 
>> Of course, you don't have to agree with me, but that puts the burden of
>> producing use cases documentation on you and others interested in taking
>> that approach. We certainly have room for both, and keep in mind that my
>> token draft is not (yet) a working group item.
>> 
>> The indication I received from many of the active members of this list is 
>> that
>> we have a strong desire to show up at Anaheim with two stable drafts. I think
>> we are very close to getting the authentication piece done following much of
>> OAuth 1.0 functionality (only cleaner and better structures), as well as
>> treating bearer tokens as first class citizens. Given that no one has 
>> started a
>> discussion about the delegation flows to include, I doubt we will have a
>> stable second draft, but I plan on getting the authentication piece stable in
>> time.
>> 
>> It has also been my experience over the past two years that the biggest
>> challenge is to figure out the authentication piece. The 'go get a token' 
>> piece
>> tends to be much easier to agree on. If we get the authentication draft to a
>> stable place, my intention is to leave it there and focus on the second part
>> and come back to it as the delegation requirements become clearer (if
>> changes are needed). But at least it gives us something stable to build upon.
>> 
>> EHL
>> 
>>> -Original Message-
>>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>>> Sent: Wednesday, February 03, 2010 7:02 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Peter Saint-Andre; OAuth WG
>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>>> 
>>> Hi Eran
>>> 
>>> I think it is a little early in our phone discussions to get into technical 
>>> details.
>>> The next step according to the last call was to gather and review use cases.
>>> Without rough consensus on what problem we are solving, your points
>>> below (which all do need to be discussed at some point) is just moving
>>> around deck chairs on the Titanic.
>>> 
>>> -- Dick
>>> 
>>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
>>> 
 Please add:
 
 - Discuss Adobe's recent request to allow excluding the host/port
 from the
>>> signed message.
 
 - With regards to #4, how should the challenge identify the token to
 be
>>> used (realm comes free, do we need another)?
 
 - Should a single token support multiple signature algorithms? This
 has
>>> implications as to the information the client has to include with the
>>> request (the algorithm used, etc.).
 
 - Where should the token structure live? OAuth 1.0 includes two
 response
>>> parameters (token and token_secret). However, since we are now moving

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Eran Hammer-Lahav]

Hi Anthony,

The problem with this approach is that it hasn't worked (multiple times) before 
because no one ever wants to do the work of collecting and writing the use 
cases. What we get instead are short cryptic lists and pointers to edge cases. 
We have a good grasp on how OAuth 1.0 is used and its limitations as addressed 
by the WRAP draft.

The best use of my time is to continue working on the drafts and asking 
technical questions whenever a decision is needed. If and when someone writes 
use cases, I will review those and see if they are supported by the drafts.
 
I will leave it up to the chairs to decide how they want to guide the working 
group.

EHL

> -Original Message-
> From: Anthony Nadalin [mailto:tony...@microsoft.com]
> Sent: Wednesday, February 03, 2010 9:02 AM
> To: Eran Hammer-Lahav; Dick Hardt
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
> 
> I would tend to agree with Dick based upon the last call and where that was
> heading. I believe that Eve had some use cases to share around UMA
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, February 03, 2010 8:41 AM
> To: Dick Hardt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Has anyone gathered and reviewed use cases? I haven't seen much of that
> showing up on the list. From my experience, asking people for use cases
> rarely works, unless someone is willing to do the work and collect them (and
> so far I haven't heard from such volunteer). I much prefer the process in
> which we produce a technical document based on OAuth 1.0 and the new
> requirements as defined by WRAP, and discuss use cases as a property of the
> technical attributes of this draft.
> 
> Of course, you don't have to agree with me, but that puts the burden of
> producing use cases documentation on you and others interested in taking
> that approach. We certainly have room for both, and keep in mind that my
> token draft is not (yet) a working group item.
> 
> The indication I received from many of the active members of this list is that
> we have a strong desire to show up at Anaheim with two stable drafts. I think
> we are very close to getting the authentication piece done following much of
> OAuth 1.0 functionality (only cleaner and better structures), as well as
> treating bearer tokens as first class citizens. Given that no one has started 
> a
> discussion about the delegation flows to include, I doubt we will have a
> stable second draft, but I plan on getting the authentication piece stable in
> time.
> 
> It has also been my experience over the past two years that the biggest
> challenge is to figure out the authentication piece. The 'go get a token' 
> piece
> tends to be much easier to agree on. If we get the authentication draft to a
> stable place, my intention is to leave it there and focus on the second part
> and come back to it as the delegation requirements become clearer (if
> changes are needed). But at least it gives us something stable to build upon.
> 
> EHL
> 
> > -Original Message-
> > From: Dick Hardt [mailto:dick.ha...@gmail.com]
> > Sent: Wednesday, February 03, 2010 7:02 AM
> > To: Eran Hammer-Lahav
> > Cc: Peter Saint-Andre; OAuth WG
> > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> >
> > Hi Eran
> >
> > I think it is a little early in our phone discussions to get into technical 
> > details.
> > The next step according to the last call was to gather and review use cases.
> > Without rough consensus on what problem we are solving, your points
> > below (which all do need to be discussed at some point) is just moving
> > around deck chairs on the Titanic.
> >
> > -- Dick
> >
> > On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
> >
> > > Please add:
> > >
> > > - Discuss Adobe's recent request to allow excluding the host/port
> > > from the
> > signed message.
> > >
> > > - With regards to #4, how should the challenge identify the token to
> > > be
> > used (realm comes free, do we need another)?
> > >
> > > - Should a single token support multiple signature algorithms? This
> > > has
> > implications as to the information the client has to include with the
> > request (the algorithm used, etc.).
> > >
> > > - Where should the token structure live? OAuth 1.0 includes two
> > > response
> > parameters (token and token_secret). However, since we are now moving
> > towards having the algorithm part of the token definition, as well as
> > duration and other attributes, the server will need to provide this
> > information to the client. This calls for a simple schema (can be any
> > format but need to agree to consistent names). It is currently part of
> > the authorization/delegation draft (implicitly), but we should discuss
> > moving it to the authentication draft since that's where it is used (the
> authorization draft sim

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Anthony Nadalin]

I would tend to agree with Dick based upon the last call and where that was 
heading. I believe that Eve had some use cases to share around UMA

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Wednesday, February 03, 2010 8:41 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting

Has anyone gathered and reviewed use cases? I haven't seen much of that showing 
up on the list. From my experience, asking people for use cases rarely works, 
unless someone is willing to do the work and collect them (and so far I haven't 
heard from such volunteer). I much prefer the process in which we produce a 
technical document based on OAuth 1.0 and the new requirements as defined by 
WRAP, and discuss use cases as a property of the technical attributes of this 
draft.

Of course, you don't have to agree with me, but that puts the burden of 
producing use cases documentation on you and others interested in taking that 
approach. We certainly have room for both, and keep in mind that my token draft 
is not (yet) a working group item.

The indication I received from many of the active members of this list is that 
we have a strong desire to show up at Anaheim with two stable drafts. I think 
we are very close to getting the authentication piece done following much of 
OAuth 1.0 functionality (only cleaner and better structures), as well as 
treating bearer tokens as first class citizens. Given that no one has started a 
discussion about the delegation flows to include, I doubt we will have a stable 
second draft, but I plan on getting the authentication piece stable in time.

It has also been my experience over the past two years that the biggest 
challenge is to figure out the authentication piece. The 'go get a token' piece 
tends to be much easier to agree on. If we get the authentication draft to a 
stable place, my intention is to leave it there and focus on the second part 
and come back to it as the delegation requirements become clearer (if changes 
are needed). But at least it gives us something stable to build upon.

EHL

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Wednesday, February 03, 2010 7:02 AM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Hi Eran
> 
> I think it is a little early in our phone discussions to get into technical 
> details.
> The next step according to the last call was to gather and review use cases.
> Without rough consensus on what problem we are solving, your points 
> below (which all do need to be discussed at some point) is just moving 
> around deck chairs on the Titanic.
> 
> -- Dick
> 
> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
> 
> > Please add:
> >
> > - Discuss Adobe's recent request to allow excluding the host/port 
> > from the
> signed message.
> >
> > - With regards to #4, how should the challenge identify the token to 
> > be
> used (realm comes free, do we need another)?
> >
> > - Should a single token support multiple signature algorithms? This 
> > has
> implications as to the information the client has to include with the 
> request (the algorithm used, etc.).
> >
> > - Where should the token structure live? OAuth 1.0 includes two 
> > response
> parameters (token and token_secret). However, since we are now moving 
> towards having the algorithm part of the token definition, as well as 
> duration and other attributes, the server will need to provide this 
> information to the client. This calls for a simple schema (can be any 
> format but need to agree to consistent names). It is currently part of 
> the authorization/delegation draft (implicitly), but we should discuss 
> moving it to the authentication draft since that's where it is used (the 
> authorization draft simply hands those "things"
> out).
> >
> > EHL
> >
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
> >> Behalf Of Peter Saint-Andre
> >> Sent: Tuesday, February 02, 2010 9:15 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> 
> >>
> >> At the first interim meeting, we didn't get through our agenda:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
> >>
> >> Therefore I propose that this time we focus on some unfinished 
> >> business, starting with the topic of authentication. I have 
> >> reviewed all of the related threads on the list and have come up 
> >> with the following
> *rough* agenda.
> >> Your feedback is welcome to improve this (a.k.a. "agenda
> >> bashing") either on the list or during the meeting.
> >>
> >> For logistics information, see here:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html
> >>
> >> **
> >>
> >> AGENDA
> >>
> >> Base proposal: draft-ietf-oauth-authentication-

Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

[Eran Hammer-Lahav]

It doesn't feel like we have much interest at this level of interoperability at 
this point.

EHL

> -Original Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Wednesday, February 03, 2010 5:38 AM
> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> An authentication challenge (WWW-Authenticate header) defined in a spec
> for an authentication mechanism should be present, but only with details
> specific to that mechanism (eg list of MAC algorithms).
> 
> I think there should be a totally separate WWW-Authenticate header
> specifically saying "a delegation flow can be used to access this resource". 
> It
> should include details such as the URI to redirect the user to.
> 
> We really need this if we want to offer a web-style protocol with any
> semblance of interoperability. If we omit it because "clients need to know
> lots of other API-specific details anyway" then we wont have a path to get
> past that limitation in future.
> 
> 
> --
> James Manger
> 
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Thursday, 28 January 2010 2:12 PM
> > To: OAuth WG (oauth@ietf.org)
> > Subject: [OAUTH-WG] What are the primary criteria in issuing an
> > authentication challenge?
> >
> > An authentication challenge (to make sure we are all on the same page)
> > is something the server sends to the client when denying access to a
> > protected resource. The challenge can be as simple as "use Basic", or
> > complex as "use Digest with the following parameters". OAuth 1.0
> > doesn't really use a challenge because it was created for cases where
> > the API calls are preconfigured and hardcoded into the client. The
> > client should never receive an OAuth challenge the way the protocol
> > was originally designed.
> >
> > In my token authentication draft I tried to propose multiple
> > mechanisms (not fully baked yet) for issuing a challenge and allowing
> > the client to figure out what to do next. Before producing another
> > draft, it is important to figure out what challenge model we want to
> > use. Here are the general options I came up with:
> >
> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
> > left on its own to figure out what to do next.
> >
> > 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> > need a new token go there". It is still not clear how this will help
> > the client given that getting a token is likely it include many
> > different options, and to fully address this we need to dig deep into
> > discovery which was left out of scope.
> >
> > 3. Token attributes - the server informs the client of the kind of
> > tokens accepted (based on their cryptographic properties or the
> > resource-set/realm they are good for). This is just like #2 but with
> > the ability for the server to support more than one token type per
> > resource.
> >
> > Question: Is the ability for a single token-protected resource to
> > support more than one token type (say Plain+SSL *and* HMAC-256) part
> > of our requirements? If not, there is no reason at all for the
> > challenge to include anything other than #1 or #2 (probably defined as
> > a future extension).
> >
> > EHL
> >
> > ___
> > 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] proposed agenda for second interim meeting

[Eran Hammer-Lahav]

Has anyone gathered and reviewed use cases? I haven't seen much of that showing 
up on the list. From my experience, asking people for use cases rarely works, 
unless someone is willing to do the work and collect them (and so far I haven't 
heard from such volunteer). I much prefer the process in which we produce a 
technical document based on OAuth 1.0 and the new requirements as defined by 
WRAP, and discuss use cases as a property of the technical attributes of this 
draft.

Of course, you don't have to agree with me, but that puts the burden of 
producing use cases documentation on you and others interested in taking that 
approach. We certainly have room for both, and keep in mind that my token draft 
is not (yet) a working group item.

The indication I received from many of the active members of this list is that 
we have a strong desire to show up at Anaheim with two stable drafts. I think 
we are very close to getting the authentication piece done following much of 
OAuth 1.0 functionality (only cleaner and better structures), as well as 
treating bearer tokens as first class citizens. Given that no one has started a 
discussion about the delegation flows to include, I doubt we will have a stable 
second draft, but I plan on getting the authentication piece stable in time.

It has also been my experience over the past two years that the biggest 
challenge is to figure out the authentication piece. The 'go get a token' piece 
tends to be much easier to agree on. If we get the authentication draft to a 
stable place, my intention is to leave it there and focus on the second part 
and come back to it as the delegation requirements become clearer (if changes 
are needed). But at least it gives us something stable to build upon.

EHL

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Wednesday, February 03, 2010 7:02 AM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Hi Eran
> 
> I think it is a little early in our phone discussions to get into technical 
> details.
> The next step according to the last call was to gather and review use cases.
> Without rough consensus on what problem we are solving, your points
> below (which all do need to be discussed at some point) is just moving
> around deck chairs on the Titanic.
> 
> -- Dick
> 
> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
> 
> > Please add:
> >
> > - Discuss Adobe's recent request to allow excluding the host/port from the
> signed message.
> >
> > - With regards to #4, how should the challenge identify the token to be
> used (realm comes free, do we need another)?
> >
> > - Should a single token support multiple signature algorithms? This has
> implications as to the information the client has to include with the request
> (the algorithm used, etc.).
> >
> > - Where should the token structure live? OAuth 1.0 includes two response
> parameters (token and token_secret). However, since we are now moving
> towards having the algorithm part of the token definition, as well as duration
> and other attributes, the server will need to provide this information to the
> client. This calls for a simple schema (can be any format but need to agree to
> consistent names). It is currently part of the authorization/delegation draft
> (implicitly), but we should discuss moving it to the authentication draft 
> since
> that's where it is used (the authorization draft simply hands those "things"
> out).
> >
> > EHL
> >
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of Peter Saint-Andre
> >> Sent: Tuesday, February 02, 2010 9:15 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> 
> >>
> >> At the first interim meeting, we didn't get through our agenda:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
> >>
> >> Therefore I propose that this time we focus on some unfinished
> >> business, starting with the topic of authentication. I have reviewed
> >> all of the related threads on the list and have come up with the following
> *rough* agenda.
> >> Your feedback is welcome to improve this (a.k.a. "agenda
> >> bashing") either on the list or during the meeting.
> >>
> >> For logistics information, see here:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html
> >>
> >> **
> >>
> >> AGENDA
> >>
> >> Base proposal: draft-ietf-oauth-authentication-01
> >>
> >> Eran had hoped to push out a new version in time for our meeting, but
> >> hasn't been able to get to it yet. However, I think we can continue
> >> to move forward with discussion. Feedback is welcome on the general
> >> approach, as well as specific open issues.
> >>
> >> Open issues
> >>
> >> Issue #1: Request Signing vs. API Signing vs. Message Signing
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.ht

Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Eran Hammer-Lahav]

Thanks James.

Your feedback is a bit late as the draft I am working on how drops the 
challenge details completely, leaving only the indication that the server 
supports the Token scheme and using a realm to help the client figure out which 
token to use (if they have more than one suitable for this resource).

The reason why it makes little sense to have different schemes for different 
types of tokens is that it is not the protected resource's job to say which 
algorithm should be used, but the server when issuing the token for that 
resource. The draft did a poor job at separating the role of the server issuing 
the tokens from the role of the server providing access to resources.

As a side note, 'class' was my placeholder parameter for replacing 'realm' (or 
at least suggesting that we take a look at that). Given the strong feeling here 
that there isn't really a current use case for servers issuing multiple tokens 
(of different properties) for a single realm and then allowing individual 
resources to reduce it to a smaller number of token types, there is no reason 
to go beyond 'realm'.

EHL

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Wednesday, February 03, 2010 5:14 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft
> 
> Hello OAuthers,
> 
> I have a couple of comments on the "Token Access Auth" draft.
> 
> Initial impression (as Eran asked for): Yuck.
> Now I will try to be a bit more constructive.
> 
> This authentication draft breaks the existing model of HTTP authentication
> too much. It puts a bunch of very different mechanisms (bearer, shared
> secret, and public key crypto) into a single "Token" scheme. We should,
> instead, have 1 scheme per mechanism, which is how HTTP auth has been
> designed.
> I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token")
> with multiple sub-schemes will not work well with existing code
> architectures, which offer extensibility based on schemes, not based on any
> other parts of a WWW-Authenticate header.
> 
> 
> It looks like 'realm' has been replaced by 'class'. This is working against 
> the
> existing model for HTTP auth, without a compelling reason.
> 
> 
> A major rational for separating OAuth into Delegation and Authentication
> documents was to recognize that they are logically independent.
> Authentication needs an id (eg a token or user-id) and, optionally, a key --
> but has no dependence on delegation. Ideally, authentication specs would
> not mention (OAuth-style) delegation at all.
> The authentication draft is too strongly bound to delegation by trying to
> package all authentication mechanisms that can be used with delegation
> under a single scheme. This cannot work.
> There will be other schemes: at lower layers, signature in the URI, signing
> excluding the host name, using password-based key agreement, using
> multiple round-trips, non-http protocols etc.
> 
> 
> I am not against developing a mechanism to sign HTTP requests with a shared
> secret. I think it is far less important for the OAuth working group than
> specifying the delegation flows, and signalling.
> 
> 
> My suggestions:
> 
> 1. Define 1 very simple bearer scheme -- with no mention of delegation.
> Don't include request signing in the same document.
>   Eg  Authorization: ID a=
>   (use "WRAP" and "wrap_access_token" as labels if you must)
> 
> 2. Optionally, work on a mechanism to sign an HTTP request with a shared
> secret without needing to exchange multiple messages with the server.
> Ensure the mechanism can include 2 ids (authentication id and authorization
> id), and a channel binding parameter.
> 
> Plus the main part of the WG work: on delegation flows; server-to-client
> signalling about how to do delegation (eg providing URI to redirect user to);
> stating which hosts and/or URIs a token (and optional secret) can be used at;
> working out how periodically refreshing credentials fits architecturally.
> 
> 
> --
> James Manger
> 
> 
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Monday, 7 December 2009 7:28 PM
> > To: OAuth WG (oauth@ietf.org)
> > Subject: [OAUTH-WG] Token Access Authentication Scheme Draft
> >
> > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
> >
> > This draft is my first attempt at defining a general purpose
> > authentication scheme to fulfill the WG requirement to produce a scheme
> > suitable for 2-legged authentication. It also supports the OAuth 3-
> > legged use cases as discussed on the list. This draft is in very early
> > stage and has been submitted early to help better facilitate the
> > conversation.
> >
> > It has been hard for us to discuss ideas without a concrete proposal. I
> > hope this will help and motivate people to participate and provide
> > feedback and new idea

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

Hi Eran

I think it is a little early in our phone discussions to get into technical 
details. The next step according to the last call was to gather and review use 
cases. Without rough consensus on what problem we are solving, your points 
below (which all do need to be discussed at some point) is just moving around 
deck chairs on the Titanic.

-- Dick

On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:

> Please add:
> 
> - Discuss Adobe's recent request to allow excluding the host/port from the 
> signed message.
> 
> - With regards to #4, how should the challenge identify the token to be used 
> (realm comes free, do we need another)?
> 
> - Should a single token support multiple signature algorithms? This has 
> implications as to the information the client has to include with the request 
> (the algorithm used, etc.).
> 
> - Where should the token structure live? OAuth 1.0 includes two response 
> parameters (token and token_secret). However, since we are now moving towards 
> having the algorithm part of the token definition, as well as duration and 
> other attributes, the server will need to provide this information to the 
> client. This calls for a simple schema (can be any format but need to agree 
> to consistent names). It is currently part of the authorization/delegation 
> draft (implicitly), but we should discuss moving it to the authentication 
> draft since that's where it is used (the authorization draft simply hands 
> those "things" out).
> 
> EHL
> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Peter Saint-Andre
>> Sent: Tuesday, February 02, 2010 9:15 PM
>> To: OAuth WG
>> Subject: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> 
>> 
>> At the first interim meeting, we didn't get through our agenda:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
>> 
>> Therefore I propose that this time we focus on some unfinished business,
>> starting with the topic of authentication. I have reviewed all of the related
>> threads on the list and have come up with the following *rough* agenda.
>> Your feedback is welcome to improve this (a.k.a. "agenda
>> bashing") either on the list or during the meeting.
>> 
>> For logistics information, see here:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html
>> 
>> **
>> 
>> AGENDA
>> 
>> Base proposal: draft-ietf-oauth-authentication-01
>> 
>> Eran had hoped to push out a new version in time for our meeting, but hasn't
>> been able to get to it yet. However, I think we can continue to move forward
>> with discussion. Feedback is welcome on the general approach, as well as
>> specific open issues.
>> 
>> Open issues
>> 
>> Issue #1: Request Signing vs. API Signing vs. Message Signing
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html
>> 
>> 1a. Seeming consensus for message signing.
>> 
>> 1b. No consensus yet on message format.
>>- JSON and textual key-value seem to be the leading candidates.
>> 
>> 1c. Seeming consensus for multiple/extensible signature algorithms.
>>- HMAC-SHA1
>>- HMAC-SHA256
>>- RSASSA-PKCS1-v1.5-SHA256
>>- PLAIN over SSL/TLS
>> 
>> But: which of these are Mandatory-to-Implement?
>> 
>> Issue #2: Include the Normalized Request with the Request?
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html
>> 
>> Seeming consensus to not include the normalized request (e.g., signature
>> string).
>> 
>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption?
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html
>> 
>> Seeming consensus that channel encryption is must-implement (which does
>> not necessarily mean must-deploy).
>> 
>> Issue #4: Authentication Challenges
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html
>> 
>> If an authentication (access) request is unacceptable, how does the server
>> tell the client how it can provide proper credentials (e.g., by using a 
>> different
>> algorithm)?
>> 
>> Possible other topics:
>> 
>> - Mutual auth?
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html
>> 
>> - Resource authorization?
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html
>> 
>> **
>> 
>> /psa
>> 
> 
> ___
> 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] What are the primary criteria in issuing an authentication challenge?

[Manger, James H]

An authentication challenge (WWW-Authenticate header) defined in a spec for an 
authentication mechanism should be present, but only with details specific to 
that mechanism (eg list of MAC algorithms).

I think there should be a totally separate WWW-Authenticate header specifically 
saying "a delegation flow can be used to access this resource". It should 
include details such as the URI to redirect the user to.

We really need this if we want to offer a web-style protocol with any semblance 
of interoperability. If we omit it because "clients need to know lots of other 
API-specific details anyway" then we wont have a path to get past that 
limitation in future.


-- 
James Manger

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, 28 January 2010 2:12 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> An authentication challenge (to make sure we are all on the same page)
> is something the server sends to the client when denying access to a
> protected resource. The challenge can be as simple as "use Basic", or
> complex as "use Digest with the following parameters". OAuth 1.0
> doesn't really use a challenge because it was created for cases where
> the API calls are preconfigured and hardcoded into the client. The
> client should never receive an OAuth challenge the way the protocol was
> originally designed.
> 
> In my token authentication draft I tried to propose multiple mechanisms
> (not fully baked yet) for issuing a challenge and allowing the client
> to figure out what to do next. Before producing another draft, it is
> important to figure out what challenge model we want to use. Here are
> the general options I came up with:
> 
> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is left
> on its own to figure out what to do next.
> 
> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> need a new token go there". It is still not clear how this will help
> the client given that getting a token is likely it include many
> different options, and to fully address this we need to dig deep into
> discovery which was left out of scope.
> 
> 3. Token attributes - the server informs the client of the kind of
> tokens accepted (based on their cryptographic properties or the
> resource-set/realm they are good for). This is just like #2 but with
> the ability for the server to support more than one token type per
> resource.
> 
> Question: Is the ability for a single token-protected resource to
> support more than one token type (say Plain+SSL *and* HMAC-256) part of
> our requirements? If not, there is no reason at all for the challenge
> to include anything other than #1 or #2 (probably defined as a future
> extension).
> 
> EHL
> 
> ___
> 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] Token Access Authentication Scheme Draft

[Manger, James H]

Hello OAuthers,

I have a couple of comments on the "Token Access Auth" draft.

Initial impression (as Eran asked for): Yuck.
Now I will try to be a bit more constructive.

This authentication draft breaks the existing model of HTTP authentication too 
much. It puts a bunch of very different mechanisms (bearer, shared secret, and 
public key crypto) into a single "Token" scheme. We should, instead, have 1 
scheme per mechanism, which is how HTTP auth has been designed.
I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token") with 
multiple sub-schemes will not work well with existing code architectures, which 
offer extensibility based on schemes, not based on any other parts of a 
WWW-Authenticate header.


It looks like 'realm' has been replaced by 'class'. This is working against the 
existing model for HTTP auth, without a compelling reason.


A major rational for separating OAuth into Delegation and Authentication 
documents was to recognize that they are logically independent. Authentication 
needs an id (eg a token or user-id) and, optionally, a key -- but has no 
dependence on delegation. Ideally, authentication specs would not mention 
(OAuth-style) delegation at all.
The authentication draft is too strongly bound to delegation by trying to 
package all authentication mechanisms that can be used with delegation under a 
single scheme. This cannot work.
There will be other schemes: at lower layers, signature in the URI, signing 
excluding the host name, using password-based key agreement, using multiple 
round-trips, non-http protocols etc.


I am not against developing a mechanism to sign HTTP requests with a shared 
secret. I think it is far less important for the OAuth working group than 
specifying the delegation flows, and signalling.


My suggestions:

1. Define 1 very simple bearer scheme -- with no mention of delegation. Don't 
include request signing in the same document.
  Eg  Authorization: ID a=
  (use "WRAP" and "wrap_access_token" as labels if you must)

2. Optionally, work on a mechanism to sign an HTTP request with a shared secret 
without needing to exchange multiple messages with the server. Ensure the 
mechanism can include 2 ids (authentication id and authorization id), and a 
channel binding parameter.

Plus the main part of the WG work: on delegation flows; server-to-client 
signalling about how to do delegation (eg providing URI to redirect user to); 
stating which hosts and/or URIs a token (and optional secret) can be used at; 
working out how periodically refreshing credentials fits architecturally.


-- 
James Manger


> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, 7 December 2009 7:28 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Token Access Authentication Scheme Draft
> 
> http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
> 
> This draft is my first attempt at defining a general purpose
> authentication scheme to fulfill the WG requirement to produce a scheme
> suitable for 2-legged authentication. It also supports the OAuth 3-
> legged use cases as discussed on the list. This draft is in very early
> stage and has been submitted early to help better facilitate the
> conversation.
> 
> It has been hard for us to discuss ideas without a concrete proposal. I
> hope this will help and motivate people to participate and provide
> feedback and new ideas. While there are many holes in the draft, it
> should be pretty easy to follow it.
> 
> Major changes from OAuth 1.0:
> 
> * New auth scheme with new parameter names
> * Signature base string replaced with normalized request string, and
> now does not require *any* encoding
> * Supports multiple token classes, authentication methods, and coverage
> scope
> 
> Main feedback requested:
> 
> * Initial impressions - this is particularly important to get. Does the
> draft make sense?
> * Functionality - does it include all the requested/required
> functionality?
> * Abstraction level - do the attributes provide the right level of
> configuration and choice?
> 
> Please refrain from editorial feedback at this point (grammar, typos,
> etc.), but do provide structural feedback.
> 
> I plan to push an updated version by Wed which will incorporate as much
> feedback as I can. I plan to ask for the WG to promote this draft to a
> WG item within 2 weeks.
> 
> Thanks,
> 
> EHL

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

Re: [OAUTH-WG] terminology

[Peter Saint-Andre]

Yes, that is quite helpful. Thanks!

On 2/3/10 1:30 AM, David Recordon wrote:
> Looks
> like 
> http://spreadsheets.google.com/ccc?key=0AjpBrc9X0st3dFBNQUpnZzFJbmFGOTkxZUVNdGdxMmc&hl=en
> 
> is actually public.
> 
> On Tue, Feb 2, 2010 at 2:08 PM, Peter Saint-Andre  > wrote:
> 
> On 1/28/10 11:35 PM, David Recordon wrote:
> > Hey Peter,
> > Luke put together a spreadsheet comparing the terminology across
> five or
> > six different protocols.  Hopefully he'll share it. :)
> 
> That would be great. I'll ping him off-list, or he can just attach it to
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by first
> provisioning an account at http://tools.ietf.org/newlogin :)
> 
> > I have a pretty strong preference of sticking with OAuth 1.0
> terminology
> > as much as possible.
> 
> Agreed.
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] terminology

[David Recordon]

Looks like
http://spreadsheets.google.com/ccc?key=0AjpBrc9X0st3dFBNQUpnZzFJbmFGOTkxZUVNdGdxMmc&hl=enis
actually public.

On Tue, Feb 2, 2010 at 2:08 PM, Peter Saint-Andre wrote:

> On 1/28/10 11:35 PM, David Recordon wrote:
> > Hey Peter,
> > Luke put together a spreadsheet comparing the terminology across five or
> > six different protocols.  Hopefully he'll share it. :)
>
> That would be great. I'll ping him off-list, or he can just attach it to
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by first
> provisioning an account at http://tools.ietf.org/newlogin :)
>
> > I have a pretty strong preference of sticking with OAuth 1.0 terminology
> > as much as possible.
>
> Agreed.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth