Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 Eran, thanks for framing this up... On Sep 28, 2010, at 12:14 PM, Brian Campbell wrote: > +1 seems like a pragmatic compromise > > On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu > wrote: >> On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher wrote: >>> +1 I think this is a great path forward >> >> +1 >> >> >> Marius >> ___ >> 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
Re: [OAUTH-WG] POLL: Are you going to Maastricht?
D On Jul 8, 2010, at 9:29 AM, David Recordon wrote: I'm honestly trying to decide myself and a few other people are in similar situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday the 27th. Thanks, --David ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] multiple access tokens from a single authorization flow?
Thanks Torsten for more of your good thinking and write-up...
At Intuit, using 1.0a, we did an experiment with one of our mobile apps using
multiple tokens. The programming model of having the client maintain a mapping
of token to ROA endpoint, so they used the correct token turned out to be a
headache. We bailed on this, and moved to a single token, and used a mechanism
server-side to manage the principle of least-privilege. As all the resources
the mobile app needed were hosted by Intuit, we had this option. As we get to
apps doing mashups of entities from multiple data providers, apps will need to
manage multiple tokens.
At Intuit, we have been wrestling with scope for several months. With 100's
going to 1000's of entities, which each have 4 - 15 verbs, expressing the set
of endpoints, which a token should allow access to is complicated. I don't see
an opportunity to normalize the complexity, so we are all interoperable on the
cardinality of tokens to the protected resources an application needs from a
specific provider. I'll push for single token in my world; others want multiple
tokens (maybe).
Experience pushes me towards providing the application developer a way to say
everything they need, and getting a single token to use in accessing those
endpoints. Much of our access control is built around an RBAC, so issuing a
token with one or more roles would provide access to all the endpoints
available to the role(s). The developer learns, from SDK documentation, the
roles an API is available to. In our case, we don't want developers
understanding how Intuit's datacenters are organized, so we would not want them
getting multiple tokens because they thought they were crossing some boundary
of our internal deployment.
Right now, multiple tokens does not help me. I am sure it could help some. My
caution to those going down the multi-token path is exposing more of your
deployment than needed by having developers get tokens for specific areas.
BillK
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Monday, May 24, 2010 9:18 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] multiple access tokens from a single authorization flow?
How many access tokens can be the result of a single OAuth authorization
flow?
A recent discussion about OpenID Connect on the OpenId mailing list
raised that question and I would like to initiate a discussion on this
list.
Currently, every flow (and the refresh token request) results in a
single access token and (optionally) a single refresh token. I think a
single access token might not be enough when it comes to multiple scopes.
Let's assume a client wants to access the calendar and contact list of
an end-user. Since access to the corresponding resource servers is
managed by the same authorization server, the resources are
distinguished by different scopes, say "calendar" and "contacts".
The client sends a request
GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri=
https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1
Host: oauth.example.com
and after the authorization flow has been conducted sucessfully, the
client's access token request would be answered as follows.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8"
}
So the token "SlAV32hkKG" must be good for two different protected
resources, "calendar" and "contacts".
I think this works if:
1) the token is a handle that can be swoped for user identity and
authorization data during service request or
2) it is a self-contained token AND both resources are provided by the
same resource server.
But what if the authorization server issues self-contained tokens and
the resources are hosted on different, independent resource servers?
Let's assume the authorization server issues self-contained, signed, and
encrypted bearer tokens. Signature and encryption are based on shared
secrets between authorization server and resource server. In such a
scenario, operational security requires to issue different tokens with
different signature values and to encrypt those tokens with different
keys. Moreover, the resource servers might need different user
attributes and permissions, so even the tokens payload might differ.
I believe this scenario will become even more important with the advent
of OpenID Connect. With OpenID connect, every client asking for an
end-user's OpenID (+user data) and, additionally, authorization for
another resource will need at least two tokens under the assumptions
given above.
In order to support such scenarios, I would propose to return an array
of access tokens from every authorization flow and the refresh request.
An authorization server should know which resou
[OAUTH-WG] how does the spec move forward
For the ignorant (me), how does the spec, now hosted at IETF, move forward? Do we still discuss on this list? Who does the editing work? Is .txt what we all have to read now? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 'Scope' parameter proposal
The amount of writing done on scope the past few weeks indicates this concept generates a lot of passion. I hope we will spend some time on it during IIW X and at our 20-May f2f. For me, delegation is an identity in my system authorizing my system to issue a toke to an identity, which is not in my system. The rights and privileges attached to the token will almost never be the same as the authorizing user. [My colleague, Tom Holodnik, is working on a user story around tax return data you must share with the financial aid department at a university your child is applying to.] My current thinking is to present a set of constraints in the UI presented to the authorizing user. Our systems would maintain these constrains - others may choose to encode the constraints into their opaque token. I'm having a hard time seeing how I can trust the scope parameter passed in by a delegate. Even if I could trust the passed in scope, it does not help me with access control of a complex entity model (e.g., tax return). I still need some other mechanism for access control, and I'm concerned scope defined in the specification may create unintended conflict cases with my access control model. BillK From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Panzer Sent: Tuesday, April 27, 2010 12:20 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] 'Scope' parameter proposal The old AOL Blogs API, which used AOL's OpenAuth service, provided a url= parameter on WWW-Authenticate: challenges: dev.estage.aol.com/aolblogs_api#mozTocId815750 * If authorization fails, a 401 response is returned with a WWW-Authenticate: header providing additional details. WWW-Authenticate: OpenAuth realm="AOLBlogs", status="status", msg="message", url="url" This is from 2007 ;). On Tue, Apr 27, 2010 at 11:49 AM, Torsten Lodderstedt wrote: Am 24.04.2010 02:05, schrieb Brian Eaton: On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H wrote: We mustn't drop advertisements (details in 401 responses). We mustn't drop the goal of a standard for interoperability. I share the goals, I just don't think that a specification is the way to get there. I think working examples in the wild would help enormously. Defining a scope field in a 401 response is the novel aspect that "might not actually work". Allowing a 'scope' query parameter in authz URIs is be quite separate. Yeah, I agree with that analysis. Though I don't know of any providers that are returning authorization URLs in 401 responses right now. That's novel, too. That's novel, yes. But I think no one did it before because there was no need to do so. BASIC and DIGEST don't require authorization endpoint coordinates. SPNEGO/Kerberos would be a candidate because of its architecture, but it uses the standard Kerberos mechanisms (config or DNS-based discovery via SRV records). I think there is a need for a standardized way of authorization server discovery. Using the WWW-Authentication header is better than nothing from my point of view. Alternatively, resource servers could publish their supported authentication servers via XRD or a similar mechanism. The authorization server in turn could publish its endpoints (and capabilities) the same way. regards, Torsten. ___ 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] Autonomous clients and resource owners (editorial)
With Doug in an all day mtg, we have not sync'd on this...so one of us may respond again on this topic. I think I am +1 w/ Brian E. In the flow from SAML gateway to STS to protected resource, I don't see caching both an access and refresh token as getting me any efficiency. Certainly, it adds complexity to regression testing. I appreciate the desire for symmetry on the set of flows...refresh token seems like a place for asymmetry. BillK -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, April 27, 2010 9:06 AM To: Torsten Lodderstedt; Brian Eaton Cc: Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) Same here - we don't intend to issue refresh tokens for either of these flows, and we'll only be accepting 1 time use assertions. -cmort From: Torsten Lodderstedt [tors...@lodderstedt.net] Sent: Tuesday, April 27, 2010 9:00 AM To: Brian Eaton Cc: Chuck Mortimore; Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) returning access token would suffice in this flow, from my point of view. regards, Torsten. Am 27.04.2010 um 08:33 schrieb Brian Eaton : > From my perspective, the main thing is that the assertion flow can be > used to connect existing authentication systems with APIs that are > using OAuth2 for authorization. > > This will let us leverage existing trust relationships across systems. > > Note that this breaks, however, if the flow returns a refresh token. > Refresh tokens are a new trust relationship, and they require > additional user/administrator involvement to manage. > > Cheers, > Brian > > On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt > wrote: >> +1 >> >> we need the assertion flow for the same purpose. Can we add a >> variant of the >> flow to section "End User Credentials Flows"? >> >> regards, >> Torsten. >> >> Am 26.04.2010 23:17, schrieb Chuck Mortimore: >> >> +1. >> >> Our primary use-cases for the assertion flow are for clients acting >> on >> behalf of users, and not autonomously. I believe Eran already has >> this on >> his list of feedback when the assertion flow gets edited. >> >> We also have need for a 2 legged Oauth model, and are looking at >> the client >> credentials flow for exactly that purpose. >> >> -cmort >> >> >> On 4/25/10 10:34 AM, "Foiles, Doug" wrote: >> >> I have a bit of confusion on the Autonomous Client Flows ... and spe >> cifically >> related to Eve's comment below that suggests to me that the autono >> mous >> client is NOT ALWAYS the resource owner. >> >> Can the Autonomous Client Flows support clients that ARE NOT the >> actual >> resource owner? For example for an Assertion Flow where the >> Subject of the >> SAML assertion is a user identity (and the resource owner) and not >> that of >> the client. >> >> Is the intent of the Client Credentials Flow to support something >> like >> Google's "OAuth for Google Apps domains" 2 Legged OAuth use ca >> se? >> http://code.google.com/apis/accounts/docs/OAuth.html. >> >> If the Autonomous Client Flows support clients that can act on >> behalf a >> resource owner that is not themselves ... it then seems the resourc >> e owner >> must provide some level of consent outside the OAuth specific flow. >> >> Thanks. >> >> Doug >> >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> Behalf Of >> Eve Maler >> Sent: Friday, April 23, 2010 7:21 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Autonomous clients and resource owners >> (editorial) >> >> >> Regarding the second comment I made below: I realized last night that >> Sections 3.7.1 and 3.7.2 get this more correct, by saying that an >> autonomous >> client represents a "separate resource owner". So Section 2.2 >> definitely >> needs a slight change, from: >> >> >> >> "...and autonomous flows where the client is acting for itself (the >> client >> is also the resource owner)." >> >> >> >> to something like: >> >> >> >> "...and autonomous flows where the client is acting on behalf of a >> different >> resource owner." >> >> >> >> Thanks, >> >> >> >> Eve >> >> >> >> On 21 Apr 2010, at 4:43 PM, Eve Maler wrote: >> >> >> Tacking this response to the end of the thread for lack of a better >> place to >> do it: The name "username" seems not quite apt in the case of an >> autonomous >> client that isn't representing an end-user. Would "identifier" be >> better? >> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or >> would the >> parameter be reserved for user-delegation flows? >> >> >> >> Speaking of autonomous clients, Section 2.2 -- among possibly other >> places >> -- states that an autonomous client is also the resource owner, but >> that's >> not always the case, is it? The client might be seeking access on >> behalf of >> itself. (FWIW, I made roughly this same comment on David's first >> draft on
