Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)
Regarding your “higher importance” comment on Section 1.1 about the impersonation semantic below: Eve Maler (sent from my iPad) | cell +1 425 345 6756 > On Jul 18, 2019, at 4:06 PM, Barry Leiba via Datatracker > wrote: > > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > -- > COMMENT: > -- > > I have comments below, a couple of which might have been DISCUSS except that > there have been enough eyes on this and enough DISCUSSes already, and I trust > the authors and responsible AD to do the right thing. So I’ve divided the > comments between “higher importance” and “purely editorial”. > > Of higher importance: > > — Section 1.1 — > Given the extensive discussion of impersonation here, what strikes me as > missing is pointing out that impersonation here is still controlled, that “A > is > B” but only to the extent that’s allowed by the token. First, it might be > limited by number of instances (one transaction only), by time of day (only > for > 10 minutes), and by scope (in regard to B’s address book, but not B’s email). > Second, there is accountability: audit information still shows that the token > authorized acting as B. Is that not worth clarifying? I’ve always been troubled by the same thing. A and B are, in fact, distinguishable (contra “A ... is indistinguishable from B in that context”). What i think is meant by impersonation is that A acts in B’s identity context while using the access it has been delegated, rather than its own context — whatever the extent of this access, great or small. > > — Section 8.2 — > RFC 8174 needs to be normative, along with 2119. > > — Section 2.2.2 — > > If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response. > > I always trip when I read “all” in a context like this. I think you mean > “any”, because you have “a token”. You could arguably make it “tokens” and > leave “all”, but I think changing to “any” is clearer: > > NEW > If the authorization server is unwilling or unable to issue a token > for any target service indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response and no tokens are returned. > END > > The danger with “all” is having a reader interpret the error as only occurring > when the server fails *all* services, and thinking that failing one out of > three still constitutes success. I have seen this be an issue often (not with > OAuth, but in general). If you want to be absolutely clear you could even add > to the end, “A request is successful only when all requested tokens are > issued.” > > — Section 5 — > > In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scope" claim is suggested to mitigate potential for such abuse, > as it restricts the contexts in which the delegated rights can be > exercised. > > I’m ambivalent here: is it worth also mentioning limiting the time a token is > valid and possibly make it a one-time-use token? Or is it that that’s > adequately covered in the other references and shouldn’t be repeated here? > > Also, is it worth referring (not copying) here to the advice in section 2.1 > about the importance of authentication? > > — Section 6 — > Should “TLS” here have a citation and normative reference? > > = > > Purely editorial: > > — Section 1 — > > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token, which it received in a protected resource request, for > a new token that is appropriate to include in a call to a backend > service. >
[OAUTH-WG] New User-Managed Access (UMA) drafts
Howdy folks-- Since UMA2 concepts and flows have been coming up here from time to time related to ongoing discussions and drafts, and there's an increasing number of implementers[1], the UMA group at Kantara decided to contribute the specs (known colloquially as "UMA Grant"[2] and "UMA Federated Authorization"[3]) in the hope they may be of interest as work items. We've been in touch with the chairs about doing a presentation in Prague. If you're not familiar at all with UMA2, the Introduction section of each spec gives a concise description. [1] https://kantarainitiative.org/confluence/display/uma/UMA+Implementations [2] https://tools.ietf.org/html/draft-maler-oauth-umagrant [3] https://tools.ietf.org/html/draft-maler-oauth-umafedauthz *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Server / Resource Server Coordination
Hi Thomas— The UMA Work Group that produced the “RSR” (OAuth Resource Set Registration) spec has an outstanding issue to fix the BCP190 issue that you point out. Since it’s a backwards-incompatible change, and we are taking a semantic versioning approach, we need to plot it out appropriately. We certainly welcome other comments. The V1.0.1 draft spec is currently in a public review period <http://kantarainitiative.org/confluence/display/uma/Home>, closing Nov 2. (Small tweak to Justin’s note: This spec is meant not to be specific to UMA, but rather to be potentially usable for “vanilla” OAuth and OpenID Connect as well.) Eve > On 13 Oct 2015, at 2:10 AM, Thomas Broyer wrote: > > > > On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <mailto:odig...@gmail.com>> wrote: > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's generally > assumed that both will be owned or operated by the same entity. > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature > to make it easy for other API developers to delegate to me the responsibility > of handling the auth grant process and issuing access tokens. > > It seems to me that a simple version of this could be easily done by: > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of access > granted (list of scopes, expiration datetime, HMAC signature using a shared > secret). > > Either that (and I'd use JWT then, as already proposed) or have resource > servers introspect tokens > <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 > <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11>> (the latter > doesn't preclude the former, but the format of the token is then just an > implementation detail of the AS that the RS doesn't need to know). > One advantage of requiring introspection is the easy support of revocation > without having to create a specific API to check whether a token is revoked: > you just introspect the token and directly know whether the token is valid or > not, and if it's valid you get its details (and have the RS cache the > response for a few seconds/minutes to avoid overloading the introspection > endpoint). That being said, RS knowing the tokens are JWTs allows them to > reject invalid tokens (expired, invalid signature, unexpected issuer, etc.) > without the need to check for revocation at the AS. > > 2) Providing a means (basic web UI) for Resource Server owners to register a > set of scopes for their service, along with user-understandable descriptions > of each to display when they arrive at my Authorization Endpoint. > > Either a Web UI, or an API > <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 > <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06>> (I'm not > a fan of this draft, and it incidentally violates IETF's BCP190 > https://tools.ietf.org/html/bcp190 <https://tools.ietf.org/html/bcp190>, but > I think it's a good source of inspiration) > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlg...@gmail.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
FWIW, UMA goes ahead and standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting “authorization API” that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationship between AS and RS entities. EVe > On 2 Dec 2014, at 12:14 PM, John Bradley wrote: > > Many of the proprietary introspection protocols in use return scope, role or > other meta data for the RS to make its access policy decision on. > One of the reasons for using opaque tokens rather than JWT is to prevent > leakage of that info. > > Making authentication to the introspection endpoint a MUST if additional > attributes are present is OK, I might even be inclined to say that > authentication of some sort is always required, but that might be going a bit > far for some use cases. > > We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. It > would be nice if we could standardize it. Precluding other attributes would > not be helpful for adoption. > > > One issue that we haven’t addressed in this spec is what happens if there are > multiple AS for the RS and how it would decide what introspection endpoint to > use. > Perhaps that needs to be a extension, leaving this for the simple case. > > However having more than on e AS per RS is not as unusual as it once was in > larger environments. > > John B. > > >> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > <mailto:jric...@mitre.org>> wrote: >> >> Agreed, which is why we've got space for the "sub" and "user_id" fields but >> not anything else about the user, and we've got a privacy considerations >> section for dealing with that. If you can help make the wording on that >> section stronger, I'd appreciate it. >> >> -- Justin >> >> On Dec 2, 2014, at 2:25 PM, Bill Mills > <mailto:wmills_92...@yahoo.com>> wrote: >> >>> If introspection returns any other user data beyond what is strictly >>> required to validate the token based solely on possession of the public >>> part it would be a mistake. >>> >>> >>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." >>> mailto:jric...@mitre.org>> wrote: >>> >>> >>> That's all fine -- it's all going over TLS anyway (RS->AS) just like the >>> original token fetch by the client (C->AS). Doesn't mean you need TLS >>> *into* the RS (C->RS) with a good PoP token. >>> >>> Can you explain how this is related to "act on behalf of"? I don't see any >>> connection. >>> >>> -- Justin >>> >>> On Dec 2, 2014, at 2:09 PM, Bill Mills >> <mailto:wmills_92...@yahoo.com>> wrote: >>> >>>> Fetching the public key for a token might be fine, but what if the >>>> introspection endpoint returns the symmetric key? Data about the user? >>>> Where does this blur the line between this and "act on behalf of"? >>>> >>>> >>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." >>>> mailto:jric...@mitre.org>> wrote: >>>> >>>> >>>> The call to introspection has a TLS requirement, but the call to the RS >>>> wouldn't necessarily have that requirement. The signature and the token >>>> identifier are two different things. The identifier doesn't do an attacker >>>> any good on its own without the verifiable signature that's associated >>>> with it and the request. What I'm saying is that you introspect the >>>> identifier and get back something that lets you, the RS, check the >>>> signature. >>>> >>>> -- Justin >>>> >>>> On Dec 2, 2014, at 1:40 PM, Bill Mills >>> <mailto:wmills_92...@yahoo.com>> wrote: >>>> >>>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>> >>>>> I don't know if that's true. POP tokens (as yet to be fully defined) >>>>> would then also have a TLS or transport security requirement unless there >>>>> is token introspection client auth in play I think. Otherwise I can as >>>>> an attacker take that toklen and get info about it that might be useful, >>>>> and I don't think that's what we want. >>>>> >>>>> -bill >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01
In case the UMA model of establishing and conducting loosely coupled AS-RS relationships is of interest, you can find more information here: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10 (for the AS's protection API, the OAuth token securing that API, and the declaration of AS config data including endpoints) http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03 (for the resource set registration sub-API) Eve On 22 Aug 2014, at 1:35 AM, Hannes Tschofenig wrote: > Hi Tiru, >> ... >>> ... >>> b) You describe a key establishment scheme to be used between the >>> resource server and the authorization server. What assumption do you make >>> about the relationship between the authorization server and the resource >>> server? Are they supposed to have a business relationship or some other >>> relationship with each other ? >> >> Authorization and Resource servers could have a business relationship >> (loosely coupled, for example Enterprise network using TURN server provided >> by third party provider like Akamai) or could be deployed in the same >> administrative domain (tightly coupled, for example Google providing both >> WebRTC and TURN servers) > > I guess you assume that there is some long-term secret (such as > asymmetric credential) in place and you then derive the symmetric keys > from it (by using DSKPP). Maybe you want to say that (in addition to the > assumed relationship between the two entities). If there is no > relationship between the two parties then they will certainly be a > challenge to get this done securely. Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
that alternative discussed, so I thought I’d bring it up. >>>> >>>> >>>> I also second Phil’s comment that it would be good to understand the use >>>> cases that this is intended to solve before embarking on a particular >>>> solution path. >>>> >>>> >>>> -- Mike >>>> >>>> >>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher >>>> Sent: Tuesday, July 29, 2014 3:25 PM >>>> To: Phil Hunt; Thomas Broyer >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token >>>> Introspection" as an OAuth Working Group Item >>>> >>>> >>>> We also have a use case where the AS is provided by a partner and the RS >>>> is provided by AOL. Being able to have a standardized way of validating >>>> and getting data about the token from the AS would make our implementation >>>> much simpler as we can use the same mechanism for all Authorization >>>> Servers and not have to implement one off solutions for each AS. >>>> >>>> Thanks, >>>> George >>>> >>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>> >>>> Could we have some discussion on the interop cases? >>>> >>>> >>>> Is it driven by scenarios where AS and resource are separate domains? Or >>>> may this be only of interest to specific protocols like UMA? >>>> >>>> >>>> From a technique principle, the draft is important and sound. I am just >>>> not there yet on the reasons for an interoperable standard. >>>> >>>> >>>> Phil >>>> >>>> >>>> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>>> >>>> Yes. This spec is of special interest to the platform we're building for >>>> http://www.oasis-eu.org/ >>>> >>>> >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>> wrote: >>>> >>>> Hi all, >>>> >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >>>> work item. >>>> >>>> We would now like to verify the outcome of this call for adoption on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>> >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion (Yes/No). >>>> >>>> The confirmation call for adoption will last until August 10, 2014. If >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for Adoption. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> ___ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /tɔ.ma.bʁwa.je/ >>>> >>>> ___ >>>> 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/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>>>> >>>>>> Yes. This spec is of special interest to the platform we're building for >>>>>> http://www.oasis-eu.org/ >>>>>> >>>>>> >>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>>>> adopting the "OAuth Token Introspection" >>>>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >>>>>> work item. >>>>>> >>>>>> We would now like to verify the outcome of this call for adoption on the >>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>> >>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >>>>>> as to the suitability of adopting this document as a WG work item, >>>>>> please send mail to the OAuth WG list indicating your opinion (Yes/No). >>>>>> >>>>>> The confirmation call for adoption will last until August 10, 2014. If >>>>>> you have issues/edits/comments on the document, please send these >>>>>> comments along to the list in your response to this Call for Adoption. >>>>>> >>>>>> Ciao >>>>>> Hannes & Derek >>>>>> >>>>>> >>>>>> ___ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> ___ >>>>>> 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/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/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
Yes. This spec is of particular interest to UMA, for which it's valuable to have a standardized and interoperable way to perform run-time token introspection at the AS. To see how UMA uses profiles the existing token introspection spec, see this section and its subsections: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10#section-3.3 Eve On 28 Jul 2014, at 10:33 AM, Hannes Tschofenig wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG > work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)
I agree with Mike's point about flexibility. If OpenID Connect expects JWT and specific claim semantics, that makes sense in the context of its use case, but there are lots of other choices that can be made. For example, UMA's MTI token profile* defines a mechanism for conveying JSON-formatted permissions (à la Anil Saldhana's "entitlement" model** vs. "enforcement" for cloud authorization), and other token profiles could be created to convey JWT claims, the results of policy decisions, the applicable policies themselves, etc. Eve * http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09#section-3.3.2 ** http://anil-identity.blogspot.com/2013/05/access-control-best-practices.html On 25 Apr 2014, at 1:18 PM, Mike Jones wrote: > To be clear, access tokens are opaque in OAuth and I don’t see any of us > trying to change that in the general case. Particular authorization servers > may use JWTs as an access token format, but that’s their private choice. I > know of other authorization servers that have the access token value be an > index into a local database table, which is just as legitimate a choice as > using a structured access token. > > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell > Sent: Friday, April 25, 2014 1:12 PM > To: Bill Burke > Cc: oauth > Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: > draft-ietf-oauth-jwt-bearer Shepherd Write-up) > > I think it is kind of assumed, yeah. And JWT as it is gives you everything > you need for that as long as the AS and RS can agree on keys, JWE and/or JWS, > and how the claims will look. I suspect that's what most deployments are > doing with JWT access tokens today. We are, or offer JWS + JWT access tokens > as an option in product anyway, and I believe many others are doing the same. > > IHMO getting everyone to agree on the specific claims etc. needed for a > standardized JWT access token is a bit of a rat's nest, which is why there's > not been much progress in that area. > > > > > > > On Fri, Apr 25, 2014 at 1:51 PM, Bill Burke wrote: > Thank you. Thats what I thought. Is it just assumed JWT would/might be used > an access token format for Bearer token auth? Or is there another draft > somewhere for that? Is anybody out there using JWS + JWT as a access token > format? > > > On 4/25/2014 2:59 PM, Brian Campbell wrote: > draft-ietf-oauth-jwt-bearer is only about interactions (client > authentication and JWT as an authorization grant) with the token > endpoint and doesn't define JWT style access tokens. > > > On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke <mailto:bbu...@redhat.com>> wrote: > > Red Hat Keycloak [1] only supports basic auth for client > authentication as suggested in the OAuth 2 spec. But our access > tokens are JWS signed JWTs. > > Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth > [2]? Or is there another document I should be following? I'd like > to see what other claims are being discussed related to JWT-based > access tokens and may have some additional access token claims we've > been experimenting with others might be interested in. > > Also, I'm not sure yet if we'll implement > draft-ietf-oauth-jwt-bearer to authenticate clients. A lot of our > initial users are more interested in public clients and/or the > implicit flow as they are writing a lot of pure javascript apps > served up by simple static web servers. > > [1] http://keycloak.org > [2] http://tools.ietf.org/html/__rfc6750 > <http://tools.ietf.org/html/rfc6750> > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Hi Hannes-- The UMA Core spec currently points directly to the basic dynamic client reg doc with MAY statements, and is agnostic as to usage of the higher-order functions. (These turn into optional interop feature tests.) So I think it's fair to say that the split has no structural problems from an UMA perspective. Eve On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig wrote: > Hi all, > > as you have seen from the meeting minutes of our recent status chat it > is time to proceed with the dynamic client registration work. > > The earlier version of the dynamic client registration document was > split into three parts, namely > (1) the current working group draft containing only minimal > functionality, > (2) a document describing meta-data, and > (3) a document containing management functionality. > > This change was made as outcome of the discussions we had more or less > over the last 9 months. > > The latter two documents are individual submissions at this point. New > content is not available with the recent changes. So, it is one of those > document management issues. > > I had a chat with Stephen about WG adoption of the two individual > submissions as WG items. It was OK for him given that it is a purely > document management action. However, before we turn the documents into > WG items we need your feedback on a number of issues: > > 1) Do you have concerns with the document split? Do you object or > approve it? > 2) Is the separation of the functionality into these three documents > correct? Should the line be drawn differently? > 3) Do you have comments on the documents overall? > > We would like to receive high-level feedback within a week. We are also > eager to hear from implementers and other projects using the dynamic > client registration work (such as OpenID Connect, UMA, the > BlueButton/GreenButton Initiative, etc.) > > For more detailed reviews please wait till we re-do the WGLC (which we > plan to do soon). We have to restart the WGLC due to discussions last > years and the resulting changes to these documents. > > Ciao > Hannes & Derek > > PS: Derek and I also think that Phil should become co-auhor of these > documents for his contributions. > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04
Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth and Justin's token introspection draft. Token introspection on its own is a "shallow" kind of loose coupling between authorization servers and resource servers. If these are operated by different organizations, as appears to be the case for you, then "deep" loose coupling may be need to answer questions about how the AS and RS onboard and establish trust with each other. UMA provides one set of answers for how to do this. You can find more info at http://tinyurl.com/umawg. Eve On 22 Oct 2013, at 7:50 AM, Thomas Broyer wrote: > Hi all, > > In a platform we're building, we have AS, clients and PRs all as distinct > parties managed/provided by distinct companies. There's a single AS though, > doing SSO through OpenID Connect (i.e. the AS in an OP). > > I thus need a way for a PR to ask the AS whether the token presented by the > client is valid and grants access to the PR. I've thus briefly evaluated > draft-richer-oauth-introspection-04 which seemed to fulfill my needs. Here > are my comments: > > First, I'm a bit disturbed about privacy and potential security issues about > the way this is done (disclaimer: I'm in no way a security expert). This > draft is really about "introspection", and not "validation" of a token, and > that might be the problem: it returns the information about a token to > whoever asks for it (provided it authenticates, and possibly only if the > token grants it access, but that would mean there's an association in the AS > between scopes and registered PRs, themselves identified by a client_id); > this is IMO disclosing too much information. > In case the PR is compromised, this information could be used to then reuse > the token with other PRs inferred by the token's granted scopes and gain > access to private information in a way that the End User didn't explicitly > approved (he authorized the Client to access several PRs, he didn't authorize > exchanges between PRs directly). This could be mitigated by *not* using > Bearer tokens (using some sort of 'proof token' instead, e.g. either MAC or > JWT), but there's no reason we couldn't have such a feature/endpoint that > could work securely with Bearer tokens (I don't want to put too much burden > on client and PR implementers). > Before I saw this draft, my idea was to have an endpoint at the AS where the > PR would send the token received by the Client *and* the scopes corresponding > to the request being done (and the "sub" of the End-User if it was part of > the request; in our case, we use it as a global identifier shared by all > parties involved; we might change to per-party IDs and then use that endpoint > to "translate" the ID as known by the Client to the ID as known by the PR, > but this is another story), and the AS would answer with just a "yes" > (HTTP/1.1 204 No Content) or "no" (400 Bad Request with a JSON payload > similar to the Error Response from Section 5.2 or RFC 6749, with the same > error codes as defined by RFC 6750; that way the PR can just "translate" the > error response to a WWW-Authenticate: Bearer response header). That way, the > PR does not know where else the token is "valid", i.e. what it could do with > it. > > Second thing, the draft talks about a "resource_id" but doesn't say how it > could be used, and whether it'll be used at all by the server, what impact it > could have on the response, etc. Could that resource_id replace the "list of > scopes" from my implementation idea? The PR would need to know the list of > scopes to return the correct WWW-Authenticate header anyway (assuming a > Bearer token is used here), so I'm not sure it's really better. And the > resource_id is optional, so what would happen if it's not provided? you'd > have *more* information returned? I understand that this is just a framework > and each server would have its own rules, but you're then either saying too > much or too few. > > Thanks in advance for any guidance about how to achieve my goal. Should I go > with introspection? (maybe I misunderstood something, or saw a threats where > there isn't) or should I use something else? Does my initial idea make sense? > Should I go with it? > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refactoring Dynamic Registration
Unfortunately I haven't been able to attend the design meetings, but I've continued to follow along here with interest. I confess that the core/management split seems a little artificial to me. I can imagine a potential use case for splitting things this way -- even a client that was *statically* provisioned its credentials might still want to manage its representation at the authorization server over time. But even so, I would normally expect to see all of this considered part of the "management" bucket, with the first step allowed to happen either on-stage or off-stage. In any case, if the split satisfies some other need I'm missing, I don't want to stand in the way. Also, I'm still a little stumped at the reluctance to allow a full set of management operations. Is this still a concern over similarity to SCIM, which also has a full set of CRUD-type operations? If so, perhaps it's worth pointing out that many (millions?) of APIs leverage the HTTP verbs in nearly identical ways to "provision" web resources. In fact, my SCIM-related slideware even says "If you've seen one RESTful CRUD API, you've seen 'em all" :), and points out that its unique value is in the *nature* of the resources being provisioned (scoped to user identity data, as noted in the SCIM API spec itself). Similarity like this is a feature of REST, not a bug. As an aside, I'm surprised the core spec has a SHOULD around open registration. Different APIs have different business models, and the range of possibilities legitimately includes APIs that require approval workflows etc. for onboarding devs and their client apps. In fact, that's one of the exciting things about defining dynamic (machine-to-machine) client registration that can nonetheless put gates in front of client provisioning: it makes OAuth protection more easily achievable even in "circle of trust" scenarios. Net on the important bits: - I'm weakly in favor of a recombined core+management spec but I'm fine with the split if others find it valuable. - I'm in favor of keeping the management functions in scope. Eve On 27 Aug 2013, at 11:52 AM, John Bradley wrote: > I appreciate that is your opinion. Lets finish splitting the document and > agree on what we agree on, then the chairs and others can render a opinion on > if http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is in > scope for this WG.I happen to think it is in scope, and I suspect I am > not alone in that. > > Right now lets focus on the core of the spec we agree on and leave the scope > issue to a later knife fight. > > John B. > > On 2013-08-27, at 2:41 PM, Anthony Nadalin wrote: > >> I believe the >> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out >> of scope for this WG and needs to go to the APPS area since we don't deal >> with other OAuth management issues >> >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Richer, Justin P. >> Sent: Tuesday, August 27, 2013 7:06 AM >> To: oauth mailing list >> Subject: [OAUTH-WG] Refactoring Dynamic Registration >> >> After last week's design team call, at Derek's suggestion, I took time today >> to refactor the Dynamic Registration draft into two pieces: "core" and >> "management". The former contains the definition of the Registration >> Endpoint and the semantics surrounding that, the latter contains the Client >> Configuration Endpoint as well as the "non-essential" client metadata >> parameters. >> >> I did this refactoring with an axe, so there are almost certainly bits and >> pieces that are in the wrong document. In particular, I've kept the use >> cases in the "core" document even though they reference concepts and >> constructs defined in the "management" spec. This way people that don't want >> to deal with a configuration management API can implement just the "core" >> registration spec and call it a day, while people who want to have full >> lifecycle control can do the "management" spec on top of it. This does >> increase the optionality by making the client configuration endpoint >> parameters optional, but that's the tradeoff for having things cut this way. >> >> You can read both the specs here: >> >> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00 >> >> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 >> >> I've uploaded these as individual submissions for now. If the working group >> decides to move forward with this refactoring, I expect both documents to >> move in tandem through the RFC approval process. >> >> -- Justin Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT
://www.ietf.org/proceedings/87/slides/slides-87-oauth-2.pptx >>>>>> >>>>>> * SCIM vs. current dynamic client registration approach for >>>>>> interacting with the client configuration endpoint >>>>>> >>>>>> In the past we said that it would be fine to have a profile defined in >>>>>> SCIM to provide the dynamic client registration for those who implement >>>>>> SCIM and want to manage clients also using SCIM. It might, however, be >>>>>> useful to compare the two approaches in detail to see what the >>>>>> differences are. >>>>>> >>>>>> * Interactions with the client registration endpoint >>>>>> >>>>>> Justin added some "life cycle" description to the document to motivate >>>>>> some of the design decisions. Maybe we need to discuss those in more >>>>>> detail and add further text. >>>>>> Additional text could come from the NIST Blue Button / Green Button >>>>>> usage. >>>>>> >>>>>> * Aspects that allow servers to store less / no state >>>>>> >>>>>> - - From the discussions on the list it was not clear whether this is >>>>>> actually accomplishable with the current version of OAuth. We could >>>>>> explore this new requirement and try to get a better understanding how >>>>>> much this relates to dynamic client registration and to what extend it >>>>>> requires changes to the core spec. >>>>>> >>>>>> >>>>>> What would you like to start with? Other topics you would like to bring >>>>>> up? >>>>>> - -BEGIN PGP SIGNATURE- >>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>>>>> Comment: GPGTools - http://gpgtools.org >>>>>> >>>>>> iQEcBAEBCgAGBQJSEULvAAoJEGhJURNOOiAtttEH/Aogg8Q/R/L9/mzU05IQbnze >>>>>> AdXB1ZvySkV3jZT4I5shmP7hQr6mc6P6UdvyOrSjrvPlBHen55/oa5z7Cwchd1dk >>>>>> dcDUEavbodjnm9SrOs0nKaTvdeZimFSBkGMrfhoTYLXpymP24F9PZgwUXdOcFocF >>>>>> OiCs3qDajYaA395DCg5+4mOLQQgDnmy4drlgj2NPv1nMBRDBubzgAhJccwF2BLN9 >>>>>> IW7MAwTEu7vYT/gwIFzriPkui7gYpf8sAqsnzf/z7FtXbsP8imgOKUlQxzZzeSSP >>>>>> QEb6+syyMD9Gt6wxQfWzyl5T0bYLP6DQ+ldZR8yGKCwb+2k3LN6Q8bIpj4mIERI= >>>>>> =tkGT >>>>>> - -END PGP SIGNATURE- >>>>>> -BEGIN PGP SIGNATURE- >>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>>>>> Comment: GPGTools - http://gpgtools.org >>>>>> >>>>>> iQEcBAEBCgAGBQJSEUQfAAoJEGhJURNOOiAt8wkIAI3xgdsWuOB36KLiMLRUG+Zb >>>>>> RvYqV+rOH80m7YVJcdOLjQJcpPqOIBdzq/yuNiAaF1uFJCqBn97ZQ/NLXLNGcg8x >>>>>> wI/Laz7kP2U4B2trBTMtAf2wsY9uYw4Eh+eOEDKGF6cmkEzrzrlw4q/Sfu6vy181 >>>>>> VI+kqwzZ+iYX4iL3NYPlkg3rwF4OZ1v3T08Erg2SPrbmNd1TRfJJU8HrYFEJQo1q >>>>>> p0RiLjcFFDCEZs0gDr9zliCXllV7J9h2ttqLq8+xwPATDuO6buQdFS9vZQ8t1u36 >>>>>> a0FIuy3NM8PQbblC3B5WumUjW4kntLV09ytYV8h6S8C/dgFwMqzAwEAeNx1exyE= >>>>>> =3qNI >>>>>> -END PGP SIGNATURE- >>>>>> ___ >>>>>> 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/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10
Coming in late to this thread: I agree broadly with Justin, Mike, and John.
Having an in-band just-in-time registration capability is valuable. By analogy
with user identifiers, it's useful for client identifiers to be issued for the
asking as the first rung of an assurance (real-world identification/strong
ongoing correlation) ladder. UMA definitely needs this because it requires
further, finer-grained authorization to assign any significant access rights to
clients and their wielders ("requesting parties") -- getting a token is, by
itself, not very meaningful. If you want, you can consider this approach a
mitigation of the risks in issuing client IDs for the asking...
Eve
On 21 May 2013, at 1:28 PM, John Bradley wrote:
> I agree with Mike, I don't think we are loosing anything, only gaining.
>
> I think it is a false statement to say that having multiple client instances
> with the same client_id and secret is a feature.
>
> In reality with public clients or public clients masquerading as private ones
> the only real way for the AS to tell them apart in OAuth is by redirect_uri.
> We are not changing that, though we are perhaps making it cleaner that
> client_id for public clients can't be relied upon in any way. Previously we
> had what was more or less assumed to be a one to one mapping of client_id to
> redirect for native clients.
>
> Once we start assigning unique client_id to instances of clients that are all
> going to be using the same redirect_uri there are a lot of question a AS has
> to decide, such as can two client_id register the same redirect_uri? That
> could well cause all sorts of race conditions on the device if you have two
> apps fighting over the same custom scheme.
>
> So I think in reality the piece of information that a registration server
> that is going to need to look at is the custom url scheme for apps, probably
> disallowing multiple anonymous registrations for the same custom scheme.
>
> Getting into the details of how app stores allocate schemes to developers etc
> is out of scope for this spec. Someone can build something more
> sophisticated on top of dynamic registration, but there are a lot of issues
> outside of the simple how is a client registering for a client_id and secret
> without forcing a manual step through a web portal.
>
> I honestly don't think adding some new application identifier solves the
> problem. That information is in the redirect_uri for native apps, and the
> problem doesn't exist for web server clients.
>
> John B.
>
> On 2013-05-21, at 2:28 PM, Mike Jones wrote:
>
>> What is the loss of information that you’re concerned about? It seems odd
>> to me that you’re asserting that there's information loss when the
>> operations performed by Dynamic Client Registration are equivalent to those
>> that are performed by out-of-band OAuth developer portals today. It’s just
>> automating a formerly manual process.
>>
>> -- Mike
>>
>>
>> From: Phil Hunt
>> Sent: Tuesday, May 21, 2013 11:20 AM
>> To: Mike Jones
>> Cc: Justin P. Richer, oauth@ietf.org WG
>>
>> Mike,
>>
>> There is an operational loss of information in the dynamic registration spec.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> On 2013-05-21, at 10:52 AM, Mike Jones wrote:
>>
>> No information is being thrown away. Developers can use dynamic
>> registration to obtain a client_id and then have all the client instances
>> use that client_id if they choose - just like they can do when doing
>> out-of-band registration with a site’s developer portal. The only
>> difference is that they don’t have to do out-of-band registration anymore!
>>
>> -- Mike
>>
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT - scope claim missing
that is encoded in a JWS or JWE, enabling the claims to be >> digitally signed or MACed and/or encrypted. >> >> So OAuth or other profiles may define claims to go in a JWT, but the JWT >> needs to itself only define the claims necessary for security processing. >> >> John B. >> PS that was a soft ball If you hadn't responded I would have been >> disappointed. I din't pick the title for the bearer token profiles. >> >> >> On 2013-02-28, at 10:12 AM, Phil Hunt wrote: >> >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> >> >> Note the title says "for OAuth2" >> >> Sorry. Couldn't resist. >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 9:40, John Bradley wrote: >> >> JWT is an assertion( I am probably going to regret using that word). >> >> It is used in openID connect for id_tokens, it is used in OAuth for >> Assertion grant types and authentication of the client to the token endpoint. >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >> >> >> >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> >> >> Dosen't define JWT's use for access tokens for the RS. >> >> Bottom line JWT is for more than access tokens. >> >> John B. >> >> On 2013-02-28, at 9:28 AM, Phil Hunt wrote: >> >> Are you saying jwt is not an access token type? >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 8:58, John Bradley wrote: >> >> Yes, defining scope in JWT is the wrong place. JWT needs to stick to the >> security claims needed to process JWT. >> >> I also don't know how far you get requiring a specific authorization format >> for JWT, some AS will wan to use a opaque reference, some might want to use >> a user claim or role claim, others may use scopes, combining scopes and >> claims is also possible. >> >> Right now it is up to a AS RS pair to agree on how to communicate >> authorization. I don't want MAC to be more restrictive than bearer when it >> comes to authorization between AS and RS. >> >> Hannes wanted to know why JWT didn't define scope. The simple answer is >> that it is out of scope for JWT itself. It might be defined in a OAuth >> access token profile for JWT but it should not be specific to MAC. >> >> John B. >> On 2013-02-28, at 8:44 AM, Brian Campbell wrote: >> >> I think John's point was more that scope is something rather specific to an >> OAuth access token and, while JWT is can be used to represent an access >> token, it's not the only application of JWT. The 'standard' claims in JWT >> are those that are believed (right or wrong) to be widely applicable across >> different applications of JWT. One could argue about it but scope is >> probably not one of those. >> >> It would probably make sense to try and build a profile of JWT specifically >> for OAuth access tokens (though I suspect there are some turtles and dragons >> in there), which might be the appropriate place to define/register a scope >> claim. >> >> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt wrote: >> Are you advocating TWO systems? That seems like a bad choice. >> >> I would rather fix scope than go to a two system approach. >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 8:17, John Bradley wrote: >> >> > While scope is one method that a AS could communicate authorization to a >> > RS, it is not the only or perhaps even the most likely one. >> > Using scope requires a relatively tight binding between the RS and AS, >> > UMA uses a different mechanism that describes finer grained operations. >> > The AS may include roles, user, or other more abstract claims that the the >> > client may (god help them) pass on to EXCML for processing. >> > >> > While having a scopes claim is possible, like any other claim it is not >> > part of the JWT core security processing claims, and needs to be defined >> > by extension. >> > >> > John B. >> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig >> > wrote: >> > >> >> Hi Mike, >> >> >> >> when I worked on the MAC specification I noticed that the JWT does not >> >> have a claim for the scope. I believe that this would be needed to allow >> >> the resource server to verify whether the scope the authorization server >> >> authorized is indeed what the client is asking for. >> >> >> >> Ciao >> >> Hannes >> >> >> >> ___ >> >> 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/oauth >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> ___ >> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-02.txt
clarified what happens if the authentication is bad >>> >>> -- Justin >>> >>> >>> Original Message >>> Subject:New Version Notification for >>> draft-richer-oauth-introspection-02.txt >>> Date: Wed, 6 Feb 2013 11:24:20 -0800 >>> From: >>> To: >>> >>> A new version of I-D, draft-richer-oauth-introspection-02.txt >>> has been successfully submitted by Justin Richer and posted to the >>> IETF repository. >>> >>> Filename:draft-richer-oauth-introspection >>> Revision:02 >>> Title: OAuth Token Introspection >>> Creation date: 2013-02-06 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>> Htmlized: >>> http://tools.ietf.org/html/draft-richer-oauth-introspection-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02 >>> >>> Abstract: >>>This specification defines a method for a client or protected >>>resource to query an OAuth authorization server to determine meta- >>>information about an OAuth token. >>> >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> ___ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client cannot specify the token type it needs
Nice suggestion! Good point that both the RS and the client, respectively, have ways (illustrated by a combination of dyn-client-reg and resource-set-reg) to review/indicate abilities and preferences in engaging with the AS. Eve On 23 Jan 2013, at 10:05 AM, George Fletcher wrote: > In addition, UMA also defines a was for the RS to instruct the client on what > to present to the AS in order to receive a token that will work at the RS. At > the moment this flow is UMA specific but could probably be abstracted into a > general pattern. > > Also, there are really three parties that have to agree in order for the > client to get access to the protected resource. >a. the client -- it may only support bearer tokens and not holder-of-key >b. the RS -- it may only allow bearer tokens from trusted clients >c. the AS -- it may only issue bearer tokens > > Developing generic negotiation amongst these parties may be overkill since in > most cases the client know what RS it will be talking to and potentially even > the authorizations server(s) as well. Given that some pre-knowledge is > probably in play, a simple solution may be to allow the client to register > via the dynamic registration proposal the token types it supports and then > the AS can use that data as a filtering mechanism when the client asks for a > token. > > Thanks, > George > > On 1/23/13 12:23 PM, Eve Maler wrote: >> FWIW, some of us have made a proposal for exactly this type of standardized >> AS/RS communication: >> >> http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00 >> >> The UMA profile refers normatively to this spec, and at that higher >> profile-specific level, it has an extensive set of AS configuration data >> that includes a way to declare token types supported. It could make sense >> for an RS to register its preferences for token types supported among those >> declared in the AS config data. Should this "preferred token type" semantic >> should be sedimented down to the "draft-hardjono-oauth-resource-reg" level? >> >> Eve >> >> On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena wrote: >> >>> Think about a distributed setup. You have single Authorization Server and >>> multiple Resource Servers. >>> >>> Although OAuth nicely decouples AS from RS - AFAIK there is no standard >>> established for communication betweens AS and RS - how to declare metadata >>> between those. >>> >>> Also there can be Resource Servers which support multiple token types. It >>> could vary on APIs hosted in a given RS. >>> >>> Thanks & regards, >>> -Prabath >>> >>> >>> On Mon, Jan 21, 2013 at 10:48 AM, wrote: >>> >>> The token type shoulbe decided by resource server, which consumes access >>> token. >>> Client just re-tell the requested token type to AS. >>> Client should not specify the token type. >>> >>> >>> oauth-boun...@ietf.org 写于 2013-01-21 13:08:39: >>> >>> >>> > This is true. It's possible for the AS to vary it's behavior on >>> > scope name, but it's presumed the AS and RS have an agreement of >>> > what token type is in play. Likely a good extension to the spec. >>> >>> > >>> > From: Prabath Siriwardena >>> > To: "oauth@ietf.org WG" >>> > Sent: Sunday, January 20, 2013 7:28 PM >>> > Subject: [OAUTH-WG] Client cannot specify the token type it needs >>> >>> > >>> > Although token type is extensible according to the OAuth core >>> > specification - it is fully governed by the Authorization Server. >>> > >>> > There can be a case where a single AS supports multiple token types >>> > based on client request. >>> > >>> > But currently we don't have a way the client can specify (or at >>> > least suggest) which token type it needs in the OAuth access token >>> > request ? >>> > >>> > Is this behavior intentional ? or am I missing something... >>> > >>> > Thanks & Regards, >>> > Prabath >>> > >>> > Mobile : +94 71 809 6732 >>> > >>> > http://blog.facilelogin.com >>> > http://RampartFAQ.com >>> > >>> > ___ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > htt
Re: [OAUTH-WG] Concerning OAuth introspection
I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To the extent that it, or its constituent parts, defines endpoints, it also is a security API or set of APIs (10,000-foot view). Since its endpoints use HTTP, this gives the opportunity to ask the question: how RESTful should its APIs be? I'm hearing one firm design principle: - Make new constituent parts be consonant with the rest of OAuth design And a couple of competing soft design principles: - Make it easy to develop endpoints (especially but not exclusively client-side) - Make it flexible to accommodate lots of situations I'm suggesting considering another one, possibly ranking it lower than others: - Make its endpoints operate in a RESTful, resource-oriented way (While OAuth hasn't gone through this exercise, UMA has, and we included a DP about RESTfulness; you can see the results here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements That's why we defined draft-hardjono-oauth-resource-reg the way we did.) The dyn reg spec is a kind of bootstrapping spec, so one can expect that it would be out of the REST mainstream in any case -- its credential provisioning function is sui generis. But the functions to create and update metadata look like pretty ordinary CRUD functions that usually correspond to various POST or PUT patterns in REST. If the client metadata were conceived of as a true web resource, it's not wildly out of left field to consider defining their creation and management in high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and GET might mean, even if not allowed in the spec today. (Justin, I promise I'm not trying to give you a hard time. :-) Eve On 23 Jan 2013, at 10:54 AM, Phil Hunt wrote: > My understanding is OAuth is an HTTP protocol. It is not intended to be REST > specific or by implication be RESTful. > > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote: > >> > On the other hand, it's a useful exercise to imagine how much more benefit >> > could potentially be gotten "for free" if we look at it through a >> > pure-REST lens, not just with what's already been specified but the whole >> > picture. >> >> +1 >> >> -- Todd >> >> >> >> >> >> >> >> From:Eve Maler >> To:Sergey Beryozkin , >> Cc:Paul Bryan , "oauth@ietf.org WG" >> >> Date:01/23/2013 12:18 PM >> Subject:Re: [OAUTH-WG] Concerning OAuth introspection >> Sent by:oauth-boun...@ietf.org >> >> >> >> Agreed that REST purity may come at a cost that's too high. On the other >> hand, it's a useful exercise to imagine how much more benefit could >> potentially be gotten "for free" if we look at it through a pure-REST lens, >> not just with what's already been specified but the whole picture. >> >> If what you're registering is a client descriptor, then creating a new one, >> updating an existing one, deleting, and even patching could come for free if >> something like the following framework is used: >> >> http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 >> >> With standard libraries possibly floating around to support this framework >> (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a >> lot cheaper to support client registration on both sides of the interaction. >> >> Eve >> >> On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin wrote: >> >> > On 23/01/13 15:47, Justin Richer wrote: >> >> Which brings up an interesting question for the Registration doc: right >> >> now, it's set up as a single endpoint with three operations. We could >> >> instead define three endpoints for the different operations. >> >> >> >> I've not been keen to make that deep of a cutting change to it, but it >> >> would certainly be cleaner and more RESTful API design. What do others >> >> think? >> >> >> > IMHO the purity should be balanced against the practicality/simplicity >> > of the implementation. >> > Talking about 3 endpoints at the spec level may be treated as the exact >> > requirement to have 3 separate application endpoints for the single type >> > of activity, the registration. Can the spec be re-worded such that >> > "resources" are used instead of endpoints or similar, example, &q
Re: [OAUTH-WG] Concerning OAuth introspection
Rudely responding to myself: I'm not saying this approach should definitely be taken, just that it's a good idea to spend 15 minutes looking at the benefits and downsides of it vs. the current laser-focus approach. Eve On 23 Jan 2013, at 9:28 AM, Eve Maler wrote: > Tony took the words right out of my mouth. :-) Or, at least, the moment > someone expresses an actual need for the next piece of flexibility (beyond > "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on > the slope towards maybe benefiting from enabling more and more of the HTTP > verbs where only one or two made sense before. One way to do this is to work > within a pure-REST framework but say that only POST and GET are supported, > with all others producing an error. Over time, if DELETE is needed, it's > easier to turn it on. > > Eve > > * "The only thing worse than generalizing from one example is generalizing > from no examples at all." Not sure if Tony is expressing an actual need or > not. > > On 23 Jan 2013, at 9:21 AM, Anthony Nadalin wrote: > >> Registration has to work in a multi-tenant environment so flexibility is >> needed >> >> -Original Message- >> From: Justin Richer [mailto:jric...@mitre.org] >> Sent: Wednesday, January 23, 2013 9:18 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Because then nobody would know how to actually use the thing. >> >> In my opinion, this is a key place where this kind of flexibility is a very >> bad thing. Registration needs to work one fairly predictable way. >> >> -- Justin >> >> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>> Why not just have a physical and logical endpoint options >>> >>> -Original Message- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>> Of Justin Richer >>> Sent: Wednesday, January 23, 2013 7:47 AM >>> To: Nat Sakimura >>> Cc: Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>> >>> Which brings up an interesting question for the Registration doc: right >>> now, it's set up as a single endpoint with three operations. We could >>> instead define three endpoints for the different operations. >>> >>> I've not been keen to make that deep of a cutting change to it, but it >>> would certainly be cleaner and more RESTful API design. What do others >>> think? >>> >>> -- Justin >>> >>> >>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>> "Action" goes against REST principle. >>>> I do not think it is a good idea. >>>> >>>> =nat via iPhone >>>> >>>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>>> >>>>> (CC'ing the working group) >>>>> >>>>> I'm not sure what the "action/operation" flag would accomplish. The idea >>>>> behind having different endpoints in OAuth is that they each do different >>>>> kinds of things. The only "action/operation" that I had envisioned for >>>>> the introspection endpoint is introspection itself: "I have a token, what >>>>> does it mean?" >>>>> >>>>> Note that client_id and client_secret *can* already be used at this >>>>> endpoint if the server supports that as part of their client credentials >>>>> setup. The examples use HTTP Basic with client id and secret right now. >>>>> Basically, the client can authenticate however it wants, including any of >>>>> the methods that OAuth2 allows on the token endpoint. It could also >>>>> authenticate with an access token. At least, that's the intent of the >>>>> introspection draft -- if that's unclear, I'd be happy to accept >>>>> suggested changes to clarify this text. >>>>> >>>>> -- Justin >>>>> >>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>> Justin, >>>>>> >>>>>> This spec is looking good.. >>>>>> >>>>>> One thing I would like to recommend is to add "action"/"operation" >>>>>> to th
Re: [OAUTH-WG] Concerning OAuth introspection
Tony took the words right out of my mouth. :-) Or, at least, the moment someone expresses an actual need for the next piece of flexibility (beyond "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on the slope towards maybe benefiting from enabling more and more of the HTTP verbs where only one or two made sense before. One way to do this is to work within a pure-REST framework but say that only POST and GET are supported, with all others producing an error. Over time, if DELETE is needed, it's easier to turn it on. Eve * "The only thing worse than generalizing from one example is generalizing from no examples at all." Not sure if Tony is expressing an actual need or not. On 23 Jan 2013, at 9:21 AM, Anthony Nadalin wrote: > Registration has to work in a multi-tenant environment so flexibility is > needed > > -Original Message- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Wednesday, January 23, 2013 9:18 AM > To: Anthony Nadalin > Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > Because then nobody would know how to actually use the thing. > > In my opinion, this is a key place where this kind of flexibility is a very > bad thing. Registration needs to work one fairly predictable way. > > -- Justin > > On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >> Why not just have a physical and logical endpoint options >> >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Justin Richer >> Sent: Wednesday, January 23, 2013 7:47 AM >> To: Nat Sakimura >> Cc: Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Which brings up an interesting question for the Registration doc: right now, >> it's set up as a single endpoint with three operations. We could instead >> define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it would >> certainly be cleaner and more RESTful API design. What do others think? >> >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The idea >>>> behind having different endpoints in OAuth is that they each do different >>>> kinds of things. The only "action/operation" that I had envisioned for the >>>> introspection endpoint is introspection itself: "I have a token, what does >>>> it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this >>>> endpoint if the server supports that as part of their client credentials >>>> setup. The examples use HTTP Basic with client id and secret right now. >>>> Basically, the client can authenticate however it wants, including any of >>>> the methods that OAuth2 allows on the token endpoint. It could also >>>> authenticate with an access token. At least, that's the intent of the >>>> introspection draft -- if that's unclear, I'd be happy to accept suggested >>>> changes to clarify this text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation" >>>>> to the request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke >>>>> ... >>>>> resource_idOPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parameter >>>>> (in case it is a public client or client is authenticated with SSL mutual >>>>> authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun >>>> ___ >>>> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client cannot specify the token type it needs
FWIW, some of us have made a proposal for exactly this type of standardized AS/RS communication: http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00 The UMA profile refers normatively to this spec, and at that higher profile-specific level, it has an extensive set of AS configuration data that includes a way to declare token types supported. It could make sense for an RS to register its preferences for token types supported among those declared in the AS config data. Should this "preferred token type" semantic should be sedimented down to the "draft-hardjono-oauth-resource-reg" level? Eve On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena wrote: > Think about a distributed setup. You have single Authorization Server and > multiple Resource Servers. > > Although OAuth nicely decouples AS from RS - AFAIK there is no standard > established for communication betweens AS and RS - how to declare metadata > between those. > > Also there can be Resource Servers which support multiple token types. It > could vary on APIs hosted in a given RS. > > Thanks & regards, > -Prabath > > > On Mon, Jan 21, 2013 at 10:48 AM, wrote: > > The token type shoulbe decided by resource server, which consumes access > token. > Client just re-tell the requested token type to AS. > Client should not specify the token type. > > > oauth-boun...@ietf.org 写于 2013-01-21 13:08:39: > > > > This is true. It's possible for the AS to vary it's behavior on > > scope name, but it's presumed the AS and RS have an agreement of > > what token type is in play. Likely a good extension to the spec. > > > > > From: Prabath Siriwardena > > To: "oauth@ietf.org WG" > > Sent: Sunday, January 20, 2013 7:28 PM > > Subject: [OAUTH-WG] Client cannot specify the token type it needs > > > > > Although token type is extensible according to the OAuth core > > specification - it is fully governed by the Authorization Server. > > > > There can be a case where a single AS supports multiple token types > > based on client request. > > > > But currently we don't have a way the client can specify (or at > > least suggest) which token type it needs in the OAuth access token request > > ? > > > > Is this behavior intentional ? or am I missing something... > > > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > > > ___ > > 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 > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerning OAuth introspection
Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used: http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction. Eve On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin wrote: > On 23/01/13 15:47, Justin Richer wrote: >> Which brings up an interesting question for the Registration doc: right >> now, it's set up as a single endpoint with three operations. We could >> instead define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it >> would certainly be cleaner and more RESTful API design. What do others >> think? >> > IMHO the purity should be balanced against the practicality/simplicity > of the implementation. > Talking about 3 endpoints at the spec level may be treated as the exact > requirement to have 3 separate application endpoints for the single type > of activity, the registration. Can the spec be re-worded such that > "resources" are used instead of endpoints or similar, example, "resource > available at /a will support the following, at /b - something else", or > may be something similar, thus it will read better too from the design > point of view, and let implementers to use 1 endpoint or 3 ones, > whichever way they prefer it > > Thanks, Sergey > >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The idea >>>> behind having different endpoints in OAuth is that they each do different >>>> kinds of things. The only "action/operation" that I had envisioned for the >>>> introspection endpoint is introspection itself: "I have a token, what does >>>> it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this >>>> endpoint if the server supports that as part of their client credentials >>>> setup. The examples use HTTP Basic with client id and secret right now. >>>> Basically, the client can authenticate however it wants, including any of >>>> the methods that OAuth2 allows on the token endpoint. It could also >>>> authenticate with an access token. At least, that's the intent of the >>>> introspection draft -- if that's unclear, I'd be happy to accept suggested >>>> changes to clarify this text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation" to the >>>>> request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke >>>>> ... >>>>> resource_idOPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parameter >>>>> (in case it is a public client or client is authenticated with SSL mutual >>>>> authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
On 28 Dec 2012, at 5:58 AM, "Anganes, Amanda L" wrote:
> Hi Eve and Thomas,
>
> On 12/27/12 8:11 PM, "Eve Maler" wrote:
>
>> Amanda, thanks for the lightning-fast comments back. A couple of additional
>> notes on top of Thomas's response:
>>
>> The "scope type" language is indeed new this time -- of course this whole
>> modular spec is newly broken out, but the previous text from UMA's rev 05
>> still said "scope". (There's a new member in the JSON description of a
>> resource set that is called "type", but this is actually the resource set's
>> type: different thing.) Maybe this should just be changed back to "scope"
>> and "scope description", as we really do mean the same construct as in plain
>> OAuth, although here it's enhanced with a machine-readable description, and
>> it's mappable to resource sets that have been explicitly identified. One
>> thing we've been learning lately is that terminology impedance mismatches
>> are not worth the cost; this one is a recent back-sliding. :)
>
> I think it would make much more sense to stick with "scope" and "scope
> description". I assumed that you were trying to avoid collisions with OAuth
> by changing it, but it sounds like that is not the case.
>
> There might be a better way to denote that these are enhanced scopes, but
> "type" isn't quite right for that as it does imply a class or kind of thing
> (to which many particular things might belong), rather than a special or
> enhanced particular thing.
Our experience so far is that enhanced versions of things should just use the
name for the thing. Hence, in the UMA core spec we've finally started using
OAuth terminology directly rather than sticking with our original names (which
dated from OAuth 1.0). I for one find it a LOT clearer, now that OAuth's
architecture has become more widely understood.
>
>>
>> Eve: Regarding the sentence "Without a specific resource set identifier path
>> component, the URI applies to the set of resource set descriptions already
>> registered." in Section 2.3: I suspect this can just be deleted entirely.
>> It's redundant with the "List resource set registrations" bullet item just
>> below, which literally shows the {rsid} component of the path being absent.
>> This is the only supported method in this API that has no {rsid} path
>> component.
>> Thomas: Resource set registration API: If Alice (the RO) has already
>> previously registered some resources at the AS, then Alice will already have
>> a PAT token (and the AS knows about Alice, her PAT, her resource sets and
>> scopes). If Alice comes back again with the same PAT and forgets to
>> specificy the path component, we assume the AS is smart enough to figure out
>> which sets Alice is refering to. Does this help? (or does it still read
>> weirdly).
>>
> These two explanations are very different. If Thomas's assessment is correct,
> I would move that explanatory text up to the end of the paragraph starting
> with "The authorization server MUST present an API…" and explain that the PAT
> can also be used to figure out the {rsid} for any requests where it is left
> off (implying that the {rsid} component MAY be left off of any of the
> following API calls). Otherwise if Eve is correct and that additional caveat
> is NOT meant to be there, I would suggest removing the phrase entirely as it
> does seem to imply that {rsid} may be left off.
I think Thomas might been thinking about a different issue we have faced in the
past regarding URIs, which is the question of how protected-resource endpoints
are disinguishable per resource owner. I won't deep-dive on that issue here to
save confusion, but suffice to say I think we can remove the offending sentence.
>
>>
>> Regarding {rsreguri}: I do see it defined, in this same Section 2.3.
>> Basically this notation is simply a device to allow for referring to a
>> "resource set registration endpoint" (defined in the Terminology section) in
>> the URIs here that serve as method templates. Is there a better way to do
>> this?
>
> Yes, it is defined but not actually used to describe the API paths. The
> definition is fine but if it is there it should be used; for example the
> "Create resource set description" path should change from "PUT
> /resource_set/{rsid}" to "PUT {rsreguri}/resource_set/{rid}".
It's used just above the explanation:
The authorization server MUST p
Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
uot;scope type"s and "type" to refer to
>> the class/kind of resource set this is add to the argument above that
>> "scope type" is a misleading term.
>>
>> 2.3 Resource set registration API
>>
>> I don't understand what this sentence means: "Without a specific
>> resource set identifier path component, the URI applies to the set of
>> resource set descriptions already registered." Can you clarify?
>>
>> The {rsreguri} URI component is defined but never used. It looks like
>> all of the "/resource_set" URIs should be prefaced with this component
>> throughout the following sections?
>>
>> [1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>>
>> --
>> Amanda Anganes
>> Info Sys Engineer, G061
>> The MITRE Corporation
>> 781-271-3103
>> aanga...@mitre.org
>>
>>
>> On 12/27/12 2:24 PM, "Thomas Hardjono" wrote:
>>
>>> Folks,
>>>
>>> The OAuth 2.0 Resource Set Registration draft is essentially a generic
>>> first phase of the User Managed Access (UMA) profile of OAuth2.0.
>> This
>>> allows the RO to "register" (make known) to the AS the resources
>> he/she
>>> wishes to share.
>>>
>>> Looking forward to comments/feedback.
>>>
>>> /thomas/
>>>
>>> __
>>>
>>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Thursday, December 27, 2012 2:07 PM
>>> To: Thomas Hardjono
>>> Subject: New Version Notification for
>>> draft-hardjono-oauth-resource-reg-00.txt
>>>
>>>
>>> A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
>>> has been successfully submitted by Thomas Hardjono and posted to the
>> IETF
>>> repository.
>>>
>>> Filename:draft-hardjono-oauth-resource-reg
>>> Revision: 00
>>> Title: OAuth 2.0 Resource Set Registration
>>> Creation date: 2012-12-27
>>> WG ID: Individual Submission
>>> Number of pages: 19
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-
>> 00.t
>>> xt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
>>>
>>>
>>> Abstract:
>>> This specification defines a resource set registration mechanism
>>> between an OAuth 2.0 authorization server and resource server. The
>>> resource server registers information about the semantics and
>>> discovery properties of its resources with the authorization
>> server.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>> ___
>>> 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
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
> Chuck Mortimore 2012-12-04 10:17:12: > > > > > There's no reason why it can't be resource owner today. > > > > > > On Dec 3, 2012, at 6:06 PM, > > > > > > wrote: > > > > > > > > > +1. > > > And why it was not looked at that time? > > > > > > oauth-boun...@ietf.org 2012-12-04 01:30:55: > > > > > > > Actually, I think it is a good time to start looking at the resourse > > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had brought > > > > this up a couple of years ago.) > > > > > > > > Igor > > > > > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: > > > > I suppose, yes. I was reading it like that all the time. > > > > Whether it is or not, if it is still ok, it might be better to > > clarify it. > > > > Word like "third party" tends to be a bit of problem without > > > clearlydefining. > > > > I had similar experience in other fora. > > > > > > > > Nat > > > > > > > > Sent from iPad > > > > > > > > 2012/12/03 0:52??"zhou.suj...@zte.com.cn" ?? > > > > ???`??: > > > > > > > > > > > could be Resource owner? > > > > > > > > > > > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" > > > > ??: oauth-boun...@ietf.org > > > > 2012-12-03 16:49 > > > > > > > > ?? > > > > > > > > "ext Nat Sakimura" , "Brian Campbell" < > > > > bcampb...@pingidentity.com>, "oauth" > > > > > > > > > > > > > > > > > > > > > > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be > > > > either the client or a third party token service? > > > > > > > > > > > > > > > > > > > > Hi Nat, > > > > > > > > The current text essentially says that the assertion can either be > > > > created by the client (in which case it is self-signed) or it can be > > > > created by some other entity (which is then called the third party > > > > token service). So, this third party could be the authorization server. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > > > Of > > > > ext Nat Sakimura > > > > Sent: Monday, December 03, 2012 10:35 AM > > > > To: Brian Campbell; oauth > > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be > > > > either the client or a third party token service? > > > > > > > > Hi Brian, > > > > > > > > > > > > The assertion framework defines the Issuer as: > > > > > > > >Issuer The unique identifier for the entity that issued the > > > > assertion. Generally this is the entity that holds the key > > > > material used to generate the assertion. The issuer may be > > > > either > > > > an OAuth client (when assertions are self-issued) or a third > > > > party > > > > token service. > > > > > > > > I was wondering why it has to be either the client or a third party > > > > token service. > > > > Conceptually, it could be any token service (functionality) > > > residingin any of > > > > > > > > the stakeholders (Resource Owner, OAuth Client, Authorization Server, > > > > or > > > > a third party). > > > > > > > > > > > > I would appreciate if you could clarify why is the case. > > > > > > > > > > > > Best, > > > > > > > > -- > > > > Nat Sakimura (=nat) > > > > Chairman, OpenID Foundation > > > > http://nat.sakimura.org/ > > > > @_nat_en > > > > ___ > > > > 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/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
You're right that UMA bundles several things in the protection API (covered by the protection scope, whose keyword is actually the resolvable URI "http://docs.kantarainitiative.org/uma/scopes/prot.json";). One of those things is the use of the token status endpoint; the rest is the whole mechanism for outsourcing protection. Maybe it makes sense for us to define "protection" as a superset scope that includes a smaller scope of "introspection", which would map to using the introspection endpoint being defined in your spec. What do you think? The permissions that get returned as the result of UMA-style introspection are actually part of the definition of the "bearer" UMA token profile. Other token contents could be profiled specifically for use with UMA, or we could perhaps also reuse OAuth token profiles. The wrapper being defined in your spec for totally generic token metadata seems like a good idea; the innards could be any number of things (with their own unique metadata), such as policy yes/no decisions, the claims gathered, etc. This topic is discussed in the latter part of this slide deck: http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf Thanks! Eve On 30 Nov 2012, at 7:56 AM, Justin Richer wrote: > Hi Eve, > > Yes, you've got the right idea. In a lot of cases that we're dealing with, > the relationship between the RS and AS is set up ahead of time. So the RS > knows which AS to ask, and the AS knows how to deal with the different RS's > it cares about. UMA gives you a nice dynamic way to introduce the two, but I > think that the introduction should be a separate step from the query, since > both parts are reusable independently. > > Correct me if I'm wrong, but UMA also has the whole API for returning > permissions associated with a token, beyond just the simple current-status > message, right? Even so, I think it makes sense to decide on what the core > set of info that would come back from such a token introspection would be, > and what it means. Different types of tokens (Bearer, MAC, HOK) are going to > have different types of metadata associated with them, probably, but there > are a few core pieces (expiration, scopes) that would be common and useful. > > -- Justin > > On 11/29/2012 05:59 PM, Eve Maler wrote: >> Hi Justin-- Glad to see this moving forward. This draft seems pretty >> straightforward, and I imagine the UMA core spec could probably incorporate >> a reference out to this rather than continuing to use our custom-specified >> method for what we'd called "token status". I wanted to highlight a couple >> of things we've defined beyond what you have here, in case they're of >> interest to the wider community. >> >> This spec defines what I'd call "shallow AS/RS communication", in that it >> assumes a trust relationship and context that's set up between them >> completely out of band. UMA needed "deep AS/RS communication", which allows >> for them to live in separate domains, potentially run by disparate parties. >> (This is akin to the separation in OpenID Connect of IdPs and third-party >> claim providers, and I've heard of a number of use cases now for the same >> separation in plain OAuth.) Thus, we defined a means by which the AS and RS >> could be introduced -- it's actually just an embedded OAuth flow -- so that >> your mention of a "separate OAuth2 Access Token" option in Section 2.1 is >> dictated in UMA to be an OAuth token, with a particular scope covering the >> use of the token introspection endpoint. >> >> The API exposed by the AS (in UMA, an "authorization manager" or AM) that >> includes usage of the token introspection endpoint is called a "protection >> API", and it includes registration of information about protected resources >> so that the AS can manage the issuance of tokens that it will later be asked >> to introspect. >> >> Finally, UMA has a simple extension point, called "UMA token profile", >> defined in its (JSON-encoded) AM config data that allows the content >> associated with the token to be standardized. Actually it dictates more than >> the content; there are protocol aspects to it too, perhaps akin to OAuth's >> token profiles. >> >> If there's interest in sedimenting some of these pieces into the OAuth >> layer, we'd certainly be interested to carve out modules (where possible) >> and submit them for consideration. Note that all of these features are >> present in our http
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
Hi Justin-- Glad to see this moving forward. This draft seems pretty straightforward, and I imagine the UMA core spec could probably incorporate a reference out to this rather than continuing to use our custom-specified method for what we'd called "token status". I wanted to highlight a couple of things we've defined beyond what you have here, in case they're of interest to the wider community. This spec defines what I'd call "shallow AS/RS communication", in that it assumes a trust relationship and context that's set up between them completely out of band. UMA needed "deep AS/RS communication", which allows for them to live in separate domains, potentially run by disparate parties. (This is akin to the separation in OpenID Connect of IdPs and third-party claim providers, and I've heard of a number of use cases now for the same separation in plain OAuth.) Thus, we defined a means by which the AS and RS could be introduced -- it's actually just an embedded OAuth flow -- so that your mention of a "separate OAuth2 Access Token" option in Section 2.1 is dictated in UMA to be an OAuth token, with a particular scope covering the use of the token introspection endpoint. The API exposed by the AS (in UMA, an "authorization manager" or AM) that includes usage of the token introspection endpoint is called a "protection API", and it includes registration of information about protected resources so that the AS can manage the issuance of tokens that it will later be asked to introspect. Finally, UMA has a simple extension point, called "UMA token profile", defined in its (JSON-encoded) AM config data that allows the content associated with the token to be standardized. Actually it dictates more than the content; there are protocol aspects to it too, perhaps akin to OAuth's token profiles. If there's interest in sedimenting some of these pieces into the OAuth layer, we'd certainly be interested to carve out modules (where possible) and submit them for consideration. Note that all of these features are present in our http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission. Thanks, Eve On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." wrote: > I took some time this morning to put together a draft of Token Introspection. > This is largely based on how we implemented it here a few years ago, and I'm > hoping that this and the Ping draft can help move the conversation about > introspection forward. > > -- Justin > > Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-richer-oauth-introspection-00.txt >> Date: November 27, 2012 1:44:01 PM EST >> To: >> >> >> A new version of I-D, draft-richer-oauth-introspection-00.txt >> has been successfully submitted by Justin Richer and posted to the >> IETF repository. >> >> Filename: draft-richer-oauth-introspection >> Revision: 00 >> Title: OAuth Token Introspection >> Creation date: 2012-11-27 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >> Htmlized: >> http://tools.ietf.org/html/draft-richer-oauth-introspection-00 >> >> >> Abstract: >> This specification defines a method for a client or protected >> resource to query an OAuth authorization server to determine meta- >> information about an OAuth token. >> >> >> >> >> >> The IETF Secretariat >> > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
Preparing generically for context to be provided by the RS/host, as well as metadata provided back by the AS/AM, seems like a good idea, and hopefully doesn't have to be over-complex. Extension points can be quite simple if designed right. But I agree that the basic use case of "give me back the info about this token" should be nice and clean. Eve On 30 Nov 2012, at 11:48 AM, Justin Richer wrote: > I think this approach makes sense and it gels with the basic concept that I'd > had about the response from the introspection endpoint being extensible and, > at some level, service specific. An interesting question then is do we want > to have some kind of signaling from the client as to what they want or need > back? In other words, make it into a full query API as opposed to a single > callback. UMA starts to do this, with fields for the resource_set_id and > host_id as part of the request. The pattern that I had written would have > implicitly tied the "resource set id" to whatever client credentials were > being used to make the request, but we already have potential use cases here > (not implemented yet) of the RS wanting to provide more context to the > authorization server. One of these would be passing along the user's OIDC > id_token in addition to their access_token to help make auth decisions. > > All of that's very quickly going down the road to complexity that might crowd > out the simple case, though, so my gut instinct is to avoid it in the core > spec. Still, it's something to consider, especially if UMA wants to be > wrapped using generic introspection, and the right level of complexity in the > core could make the future much simpler. > > But even so, I think the simple case of "I have a token and want to know > about it" needs to be supported without extra scaffolding. > > -- Justin > \ Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] My earlier comments on the dyn client reg draft
Hannes suggested that, for transparency, I should share with the list the comments that I had earlier sent to Justin. Here they are. I believe these have all been addressed in one way or another by now. Eve General - Authorship: I suspect that Christian Scholz really won't mind if you move him to the acknowledgments. He actually had not that much to do with the original UMA-based draft, but was our official spec editor of the group at the time. (I wrote the bulk of the requirements, and Maciej wrote the bulk of the request/response stuff.) 1. Introduction - Para 2: s/meta information/metadata/ to match other references. 2.1. Client Association Request - Could you make it a bit clearer that the parameters you list are actually defined in Section 3? I found this confusing at first. 2.2. Client Association Response (and following) - Is it worthwhile defining a media type application/json+something for the various JSON-encoded responses defined in the doc? I'm not sure if the OAuth spec has been going to this trouble. The UMA spec does -- which means that eventually we'll have to submit to IANA for registering those types... - client_secret: s/us used/is used/ s/not required/OPTIONAL/ ? - registration_access_token: Is there any reason not to call this simple "access_token"? 2.3. Client Update Request - Para 1: Why is the empty-value interpretation a SHOULD rather than a MUST? It would seem that we'd want interoperability in how to replace/wipe metadata. 2.4. Client Update Response (and following) - For client_id in responses, does it make sense to say something like "A unique Client Identifier matching the one in the request"? 2.5. Rotate Secret Request - Having it be an error if the client never originally had a secret, and the question about rotating the access token, makes me think that we should keep things as simple as possible, and make this operation be something like "client_refresh", which always refreshes the access token and -- if it was issued a secret -- the secret as well? There's sort of a recursiveness to managing meta-secrets used to issue client identities, and the last thing we want is to embed a full-blown OAuth mechanism that makes it token turtles all the way down... 2.7. Client Registration Error Response - Trying to think of additional error conditions: invalid ID? Invalid token? These don't seem covered by the existing options. Of course, it's possible this detail shouldn't be exposed in the error response for security reasons. 3. Client Metadata - In "token_endpoint_auth_method": Is "unspecified or omitted" redundant? What's the difference? 5. Security Considerations - I assume that, eventually, the RP/IdP language from the OpenID Connect draft will need to be genericized. Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Hi Igor-- If you mean enabling (um) Grandma Goldie to delegate child pickup duties to Tom the Taxi Driver after having been herself delegated to pick up the child by Peter Parent, then -- as long as we're focusing on policy-based claims-tested authorization for requesting party access, then UMA would likely treat both cases of delegation as the normal course of business since the UMA host (RS) doesn't care how the current authorizing user (RO) "won" its own access in the first place. If we're only talking about the realm of client app (UMA requester) identities and not an actual legally liable third party, there are a number of OAuth profiling tricks that can be, and seem to have been, proposed... For folks interested in the use cases with the legally liable parties, you can find a passel of them here: http://docs.kantarainitiative.org/uma/draft-uma-trust.html (particularly the Use Cases section: http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1) http://kantarainitiative.org/confluence/download/attachments/62324760/UMA_Personal_Loan_v01.pdf - explores RO-to-organization sharing in detail These are, of course, in addition to the original (now pretty old) use cases doc I've mentioned on this list before: http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases Eve On 18 Oct 2012, at 9:53 AM, Igor Faynberg wrote: > Looks like a good description of a new use case to me! > > Igor > > On 10/17/2012 10:23 PM, zhou.suj...@zte.com.cn wrote: >> >> >> Hi, Thomas, >> >>Sorry for reply late. I somehow missed the emails from OAUTH list. >> >> "What may not be clear up-front from reading the UMA core spec is that >> there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting >> Party) and Bob's portal/platform (Requester)). >> >> Here's a more accurate picture: >> >> - I deposit my Child at the Kindergarten. >> - I delegate my old Grandmother to pick up the Child. >> - My Grandmother takes a taxi. >> - The taxi Driver acts as proxy to my old Grandmother who stays in the >> taxi. >> - The taxi Driver needs to show 2 forms of Delegation to the Teacher. >> - The Taxi driver walks the Child to the taxi. >> >> Bear in mind that my Grandmother now has to manage the delegation she >> gave the taxi Driver (plus the Scopes involved)." >> >> >> If I understand correctly, old Grandma means Bob the requesting Party, >> the taxi driver means Bob the requester in UMA? >> Not talking about UMA, Bob is not separate between roles in OAUTH, >> so don't have to redelegate in 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Sorry for the delay. Here's what I was thinking about: https://dev.twitter.com/docs/auth/oauth/oauth-echo -- The delegation here (using OAuth V1) is about client 1 delegating to client 2, still presumably operated by the same human user throughout. http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-01 - I've never fully understood this one, to be honest, but it seems different from Echo. There's also this: http://tools.ietf.org/html/draft-richer-oauth-chain-00 - This is, I believe, explicitly for scoping the delegated access smaller than it was originally. And this: http://tools.ietf.org/html/draft-hunt-oauth-chain-00 - Yet a different pattern from what I can see. I'll try and answer your other emails as soon as I can... Eve On 17 Oct 2012, at 7:28 PM, zhou.suj...@zte.com.cn wrote: > > Hi, Eve > >Sorry for reply late. I somehow missed the emails from OAUTH list. > >"If the client/requesting party is literally acting on behalf of the > initial RO, then it would seem to me that this is closer to the discussions > of "redelegation" and Twitter Echo and such from the past. UMA's use cases > have to do with authorizing delegated access that is performed on behalf of > the client itself (the word "autonomous" from OAuth 1.0 springs to mind). > Eve" > > Can you give me the link of discussion in the past you mentioned? > The usecase Hardjono rediscribed may not necessarily invloving > "redelegation", a more general case would be the Babysitter directly show > delegation to the Teacher and walk the child home. > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
If the client/requesting party is literally acting on behalf of the initial RO, then it would seem to me that this is closer to the discussions of "redelegation" and Twitter Echo and such from the past. UMA's use cases have to do with authorizing delegated access that is performed on behalf of the client itself (the word "autonomous" from OAuth 1.0 springs to mind). Eve On 11 Oct 2012, at 8:44 AM, Thomas Hardjono wrote: > Apologies for jumping in late. > > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf >> Of zhou.suj...@zte.com.cn >> Sent: Thursday, October 11, 2012 4:45 AM >> To: Eve Maler >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >> >> >> Hi,Eve >> >> "Having an RO literally being present to register a client operated > by >> some third party still seems like an unnecessary constraint to me if >> the alternative is for RO to configure their preferences and then > move >> on." >> >> --I didn't catch the significance of it either. But I think > Prabath's >> idea is not RO-initiated client registeration, but RO-initiated > access >> token delegation. >> Let RO itself decide who is to be delegated is reasonable, and > could >> be commonly seen in everday life. >> For example, I deposit my child at kindergarden, then when someone >> tries to take him outside of the kindergarden, the teacher will > inform >> me "do you authorize this guy do it"---that is what OAuth currently > do; >> But I may prefer not to be disturbed too often, I just send >> delegation statement to a few of persons, e.g., grandparents of my >> child, then when someone tries to take my child outside of the >> kindergarden, the teacher will ask him/her to show my delegation >> statement, no statement, no taking my child. that my > understanding >> of RO-initiated delegation. > > What may not be clear up-front from reading the UMA core spec is that > there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting > Party) and Bob's portal/platform (Requester)). > > Here's a more accurate picture: > > - I deposit my Child at the Kindergarten. > - I delegate my old Grandmother to pick up the Child. > - My Grandmother takes a taxi. > - The taxi Driver acts as proxy to my old Grandmother who stays in the > taxi. > - The taxi Driver needs to show 2 forms of Delegation to the Teacher. > - The Taxi driver walks the Child to the taxi. > > Bear in mind that my Grandmother now has to manage the delegation she > gave the taxi Driver (plus the Scopes involved). > > /thomas/ > > > > >> Eve Maler >> 2012-10-11 11:31 >> 收件人 >> zhou.suj...@zte.com.cn >> 抄送 >> "oauth@ietf.org WG" , Prabath Siriwardena >> >> 主题 >> Re: [OAUTH-WG] Resource owner initiated OAuth delegation >> >> >> >> >> >> >> >> Ah, right. I think I got this more correct in my initial post than > in >> this last one. Here's how I'd address this: RO Alice controls the >> access by client/requester Bob by virtue of consenting at access > token >> issuance time in Prabath's proposal, vs. setting policies that > direct >> an online service to issue it when Bob approaches in UMA. Another > way >> to say this is that access is RO-initiated in the first case and, >> perhaps, RO-directed in the second. Having an RO literally being >> present to register a client operated by some third party still > seems >> like an unnecessary constraint to me if the alternative is for RO to >> configure their preferences and then move on. >> >> (Note that if the RO and the requesting party are the same person, > the >> UMA flow looks pretty much like a regular OAuth flow because Alice > can >> configure a policy that says "Only alice@gmail can get full-scope >> access to this resource", and if Alice herself shows up using any >> client and can prove she's alice@gmail (e.g. through OpenID Connect >> claims, something we've already profiled), she's good to go.) >> >> Eve >> >> On 10 Oct 2012, at 5:40 PM, zhou.suj...@zte.com.cn wrote: >> >> >> Hi, Eve, >> The requester you described corresponds to Client in OAuth, so it > is >> still client initiated delegation, not what Prabath wants. >> >> Eve Maler >> 2012-10-11 06:54 >> >> 收件人 >> Prabath Siriwardena >> 抄送 >> zhou.suj...@
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Ah, right. I think I got this more correct in my initial post than in this last one. Here's how I'd address this: RO Alice controls the access by client/requester Bob by virtue of consenting at access token issuance time in Prabath's proposal, vs. setting policies that direct an online service to issue it when Bob approaches in UMA. Another way to say this is that access is RO-initiated in the first case and, perhaps, RO-directed in the second. Having an RO literally being present to register a client operated by some third party still seems like an unnecessary constraint to me if the alternative is for RO to configure their preferences and then move on. (Note that if the RO and the requesting party are the same person, the UMA flow looks pretty much like a regular OAuth flow because Alice can configure a policy that says "Only alice@gmail can get full-scope access to this resource", and if Alice herself shows up using any client and can prove she's alice@gmail (e.g. through OpenID Connect claims, something we've already profiled), she's good to go.) Eve On 10 Oct 2012, at 5:40 PM, zhou.suj...@zte.com.cn wrote: > > Hi, Eve, >The requester you described corresponds to Client in OAuth, so it is still > client initiated delegation, not what Prabath wants. > > > > Eve Maler > 2012-10-11 06:54 > > 收件人 > Prabath Siriwardena > 抄送 > zhou.suj...@zte.com.cn, "oauth@ietf.org WG" > 主题 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > Sure. We'll ultimately be publishing some case studies that will hopefully > make this clearer, but the key place to start in the spec is here: > > http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt-access > > " The requester typically attempts to access the desired resource at the > host directly (for example, when a human operator of the requester software > clicks on a thumbnail representation of the resource). The requester is > expected to discover, or be provisioned or configured with, knowledge of the > protected resource and its location out of band. Further, the requester is > expected to acquire its own knowledge about the application-specific methods > made available by the host for operating on this protected resource (such as > viewing it with a GET method, or transforming it with some complex API call) > and the possible scopes of access." > > So the requester can initiate the request, with the following preconditions: > > - The host (RS) has registered this resource as protected with the > authorization manager (AS). > - The requester (client)/requesting party has learned the location and > applicable API details of the resource out of band. > > The interactions among the host (RS), AM (AS), and requester (client -- > potentially operated by a third party who is not the RO) are protected with > various tokens. This is illustrated in the introduction with ASCII art... > > http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction > > The actual protected resource requires a "requester permission token" (RPT) > associated with suitable authorization data. This is an UMA-specific > construct -- admittedly not a true OAuth flow, though inspired by it! The AM > presents a protection API to the host for registering protected resources; > the API is protected by a plain-vanilla OAuth token called a protection API > token (PAT). The AM also presents an authorization API to the requester, > which is protected by a plain-vanilla OAuth token called an authorization API > token (AAT). We're counting on dynamic client registration to be in place > wherever deployers want true loose coupling. > > When the requester initiates a request, if it has no token at all, the host > directs it to the AM to get first an AAT (which conveys Bob's authorization > to use it and the AM in conveying identity claims to win authorization), and > ultimately an RPT (which convey's Alice's authorization for Bob and this > requester app to access the resource with specific scopes). Of course we're > talking about an UMA-enabled requester here, but it can literally initiate an > access request with zero tokens and ultimately get somewhere. > > We'll be demoing this whole thing next Wednesday in the webinar, including > the dynamic client reg, the PAT, AAT, and RPT, the UX for the various parties > interacting with systems, and even interesting app-level enhancements like > notifying Alice that Bob has made an access attempt and inviting her to set > up policies that let him in. > > Eve > > On 10 Oct 2012, at 3:35 PM, Prabath Siri
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Sure. We'll ultimately be publishing some case studies that will hopefully make this clearer, but the key place to start in the spec is here: http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt-access " The requester typically attempts to access the desired resource at the host directly (for example, when a human operator of the requester software clicks on a thumbnail representation of the resource). The requester is expected to discover, or be provisioned or configured with, knowledge of the protected resource and its location out of band. Further, the requester is expected to acquire its own knowledge about the application-specific methods made available by the host for operating on this protected resource (such as viewing it with a GET method, or transforming it with some complex API call) and the possible scopes of access." So the requester can initiate the request, with the following preconditions: - The host (RS) has registered this resource as protected with the authorization manager (AS). - The requester (client)/requesting party has learned the location and applicable API details of the resource out of band. The interactions among the host (RS), AM (AS), and requester (client -- potentially operated by a third party who is not the RO) are protected with various tokens. This is illustrated in the introduction with ASCII art... http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction The actual protected resource requires a "requester permission token" (RPT) associated with suitable authorization data. This is an UMA-specific construct -- admittedly not a true OAuth flow, though inspired by it! The AM presents a protection API to the host for registering protected resources; the API is protected by a plain-vanilla OAuth token called a protection API token (PAT). The AM also presents an authorization API to the requester, which is protected by a plain-vanilla OAuth token called an authorization API token (AAT). We're counting on dynamic client registration to be in place wherever deployers want true loose coupling. When the requester initiates a request, if it has no token at all, the host directs it to the AM to get first an AAT (which conveys Bob's authorization to use it and the AM in conveying identity claims to win authorization), and ultimately an RPT (which convey's Alice's authorization for Bob and this requester app to access the resource with specific scopes). Of course we're talking about an UMA-enabled requester here, but it can literally initiate an access request with zero tokens and ultimately get somewhere. We'll be demoing this whole thing next Wednesday in the webinar, including the dynamic client reg, the PAT, AAT, and RPT, the UX for the various parties interacting with systems, and even interesting app-level enhancements like notifying Alice that Bob has made an access attempt and inviting her to set up policies that let him in. Eve On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena wrote: > Hi Eve, > > I have gone through UMA spec but failed to find any case which covers this > scenario - in a resource owner initiated manner.. > > Can you please give some pointers..? > > Thanks & regards, > -Prabath > > On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote: > There are a number of implicit actions happening here that ideally should be > accounted for. If Alice is the RO and Bob is operating the client, then when > Bob accesses the protected resource it may not just be "on Alice's behalf" -- > think of how people share calendar read/write access with other people today. > Those with delegated access act on their own behalf, with the RO's > permission. So the tuple represented by the access token is actually quite a > bit bigger than usual. > > Since OAuth makes a simplifying assumption that gets it entirely out of this > sort of business, the process of trying to shoehorn this use case into a > single plain OAuth flow may end badly. Better would be an explicit > recognition of the symmetry of Alice (with her user agent) on one side, and > bob with his client on the other side. Not to sound like a broken record, but > the UMA model takes this fully into account and has even gone a fair way down > the path of considering the contractual and legal implications of such > authorization. > > Since the client (along with its operator) has to register on the AS side > anyway, having a clean model where it can do that without the RO's > synchronous presence would be ideal. Otherwise I suspect it's impractical in > normal use. > > Eve > > On 9 Oct 2012, at 6:49 PM, zhou.suj...@zte.com.cn wrote: > >> >> Hi，Prabath >> >> >> Prabath Siriwardena &g
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
There are a number of implicit actions happening here that ideally should be accounted for. If Alice is the RO and Bob is operating the client, then when Bob accesses the protected resource it may not just be "on Alice's behalf" -- think of how people share calendar read/write access with other people today. Those with delegated access act on their own behalf, with the RO's permission. So the tuple represented by the access token is actually quite a bit bigger than usual. Since OAuth makes a simplifying assumption that gets it entirely out of this sort of business, the process of trying to shoehorn this use case into a single plain OAuth flow may end badly. Better would be an explicit recognition of the symmetry of Alice (with her user agent) on one side, and bob with his client on the other side. Not to sound like a broken record, but the UMA model takes this fully into account and has even gone a fair way down the path of considering the contractual and legal implications of such authorization. Since the client (along with its operator) has to register on the AS side anyway, having a clean model where it can do that without the RO's synchronous presence would be ideal. Otherwise I suspect it's impractical in normal use. Eve On 9 Oct 2012, at 6:49 PM, zhou.suj...@zte.com.cn wrote: > > Hi，Prabath > > > Prabath Siriwardena > 2012-10-09 20:35 > > 收件人 > zhou.suj...@zte.com.cn > 抄送 > Eve Maler , oauth@ietf.org, oauth-boun...@ietf.org > 主题 > Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > > > On Mon, Oct 8, 2012 at 6:24 PM, wrote: > > Hi， Prabath > > My question is since client-id is public, then it is a waste to get it by > granting an access-token. > And in step 2."Resource Owner grants access to a selected Client", RO > logins in to select clients to be delegated, > and RS redirects RO to AS to grant access token to client, to my > understanding, in this process RO needs to authenticate to RS and then > authenticate > to AS, it is a bit complicated. > > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds some > overhead.. So - I would like to modify it - where the Resource Server sends > the resource_owner_initiated as the scope - and based on the scope AS returns > back client_id together with the access_token it self. > > > I wonder if the following two processes could satisfy your case: > > Process One: > 1. Resource Owner registers to-be-delegated clients and corresponding RSs at > AS, i.e., a long term delegation contract is stored at AS > > 2. When Resource Owner requests Client to access its resource at RS, Client > is directed by RS to AS to obtain access-token > 3. Client accesses the protected resource on behalf of the Resource Owner. > > Process Two: > 1. RO registers to-be-delegated clients at RS, i.e., a long term delegation > contract is stored at RS > 2. When Resource Owner requests Client to access its resource at RS, Client > is directed by RS to AS to obtain access-token,AS may request RO to > authenticate and confirm the > access-token request > 3. Client accesses the protected resource on behalf of the Resource Owner. > > > There needs to be an step to facilitate client registration. > Client could have registered at AS. > RO just select clients from available clients list. > This facilitating step still needed? > > Thanks & regards, > -Prabath > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
(I'm not seeing Zhou's responses to you on the list, so I don't have the other proposal handy. Can Zhou or someone share the link?) Your proposal seems to require that the requester/client register with the AS (through the RS) ahead of time as well as initiating the approach to the resource at access-request run time. This seems quite similar conceptually to UMA. The main difference, I think, is that "three-legged" OAuth pretty much assumes (though it doesn't strictly enforce) that the resource owner and the requesting party are the same person by virtue of authenticating to both the client app and the AS in a single virtual session (your step #1). UMA anticipates total separation between resource owner/authorizing user Alice and requesting party/client operator Bob, and lets Alice set up policies entirely without Bob's presence, requiring only that he present claims at access-request time. It's more akin to enterprise access control than authentication-based consent in enabling this separation. There's another example of cooking up an access token ahead of time: This is one way OpenID Connect achieves the "distributed claims" effect. If an OpenID Connect IdP isn't responsible for knowing a particular attribute, but a third-party attribute provider has registered the attribute's availability with this IdP, the IdP can let clients/RPs get access to an interim resource that contains an attribute pointer and a pre-cooked access token for using at the actual attribute provider. But again, OpenID Connect implicitlly assumes the "same user" across clients and sessions and web apps. My belief is that judiciously mixing UMA and OpenID Connect (and AXN) -- each of them already mixes in a lot of OAuth! -- could get us to a generically applicable claims-based authorization system for both attributes and arbitrary API calls. Eve On 7 Oct 2012, at 5:08 PM, Prabath Siriwardena wrote: > Hi Eve, > > Thanks for pointers.. I've been following the work done in UMA.. Sure.. will > join the webinar... > > BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA > it's client initiated or requestor initiated... > > Please correct me if I am wrong... but in OAuth specification there is no > restrictions to identify the 'client' as a person, organization or as him > self.. > > In my view - this is an extended grant type..which has two phases.. > > 1. Resource owner grants access to a selected a Client > 2. Client requests the already available access token for him from the > Authorization Server.[just like passing the refresh_token] > > WDYT ? > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler wrote: > Hi Prabath, > > As far as I know, OAuth itself generally isn't used to let one human resource > owner delegate access to a different human resource owner. However, UMA > (which leverages OAuth) does strive to solve exactly this use case, among > other similar ones; we call this one "person-to-person sharing", and you can > read more about it here: > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 > > The UMA flow at run time still ends up being effectively "client-initiated" > (we would say requesting-party-initiated, using a requester app) because the > original resource owner (we call it an authorizing party) is no longer around > by then. The authz party would set up policies at some point before going on > vacation, and these polices would enable the requesting party to "qualify in" > for access at run time, by supplying identity claims that get used in an > authorization check by the authz server (authz manager). > > We'll be walking through UMA flows and demoing an extensive use case at a > webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena wrote: > > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: > > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > ___________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.o
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Hi Prabath, As far as I know, OAuth itself generally isn't used to let one human resource owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 The UMA flow at run time still ends up being effectively "client-initiated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager). We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg Hope this helps, Eve On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena wrote: > Hi folks, > > I would like to know your thoughts on the $subject.. > > For me it looks like a concrete use case where OAuth conceptually does > address - but protocol does not well defined.. > > Please find [1] for further details... > > [1]: > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > ___________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Implementation Support and Community
Perhaps relatedly, in the UMA group we've been defining feature tests for interoperability testing, and since UMA uses OAuth, we wondered if any OAuth feature tests exist; we couldn't find any. That might be another activity worthy of being taken up by such a community. (Both UMA and OpenID Connect are using the OSIS.idcommons.net wiki for interop testing.) Eve On 23 Aug 2012, at 7:51 AM, John Bradley wrote: > The openID foundation is in a position of promoting OAuth 2 now as a > significant dependency of openID Connect and other work. > > I can ask the board if there is a interest in hosting something specific for > OAuth 2. > > I agree with Justin, now that the core spec is done there needs to be some > consideration put to marketing and support by someone. > This WG has new work items to progress so we probably don't want to get > bogged down with that in this group. > > I will wait to see the discussion on this here before asking OIDF or anyone > else if they want to set something up. > > John B. > On 2012-08-23, at 10:38 AM, Justin Richer wrote: > >> With the core specs basically out the door and seeing wider adoption and >> publicity, the OAuth community is going to start to get more questions about >> "how do I do X?", and many of these are questions that have been answered >> before or seem "obvious" to those of us who have been up to our ears in the >> spec for the past few years. Nevertheless, these are important questions to >> support for the wellbeing of the protocol community, but where should they >> be asked? >> >> When the OAuth community lived on a simple Google Group, these kinds of >> questions make sense. But I'd argue that the IETF list is not really the >> right place for them. This list, and the IETF in general, seems to be best >> suited for *building* the protocol, not for the *use* and *support* of said >> protocol once it's built. >> >> The problem is that, as of right now, we don't have anywhere to point people >> where they could get a "real" answer. >> >> This opens a larger question of who might "sponsor" or "host" such a >> community. Anything like that needs moderators, and more importantly, needs >> experts willing to answer the questions. Some options I can think of: >> >> - Revive the google groups list for these kinds of questions/discussions >> - Start a new list/forum, linked to oauth.net >> - Point everyone to StackOverflow with an "oauth" tag >> >> >> -- Justin (who is not volunteering himself to host or moderate the group) >> ___ >> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration.
FWIW, the reason we ultimately went with JSON was that it removed stumbling blocks around implementation and sheer spec volume. When we used straight XRD, we found that we had to put a full worked example in an appendix so it didn't impede the flow of the spec, and implementers reported to us that JSON would have been much preferable for producing and consuming the config data. When we found the OpenID Connect example, it was a natural fit and so we copied it. (Not trying to open up past "JRD" discussions, just sharing our experience... If OAuth ultimately absorbs some XRD-formatted hunk of machine-discoverable config data, we'll leverage it.) Eve On 13 Jun 2012, at 11:59 AM, William Mills wrote: > We certainly overlap, the thing you have that is not in the link type > registrations is dynamic_client_registration_supported. We should be > consistent in naming, and ideally the OAuth related JSON elements from a JSON > format Webfinger request and your UMA stuff shoudl be identical. My concern > with using a JSON list structure for capability lists is how it would play in > the LINK header itself, that seems a bit hairy to put a JSON list inside a > quoted application data value. > > Do we want something like a "capabilities" list which could include > dynamic_client_registration_supported and perhaps others? > > -bill > > > > > - Original Message - >> From: Eve Maler >> To: William Mills >> Cc: Goix Laurent Walter ; Peter >> Saint-Andre ; O Auth WG ; Apps Discuss >> >> Sent: Wednesday, June 13, 2012 11:38 AM >> Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. >> >> Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a >> need >> for the authorization server to provide OAuth-related metadata along with >> UMA-specific metadata. Originally it was strictly XRD- and hostmeta-based, >> but >> now uses a JSON format and is more akin to OpenID Connect's metadata in >> style: >> >> http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints >> >> Do you feel that this new draft is something that ultimately *should* >> replace >> the OAuth-specific parts of the metadata we've spec'd out for our use >> case? Note that we went beyond just the two endpoints, also covering a >> feature >> toggle for "dynamic_client_registration_supported" and lists of >> "oauth_token_profiles_supported" and >> "oauth_grant_types_supported". The purpose in doing this was to >> provide a machine-readable mechanism for aiding OAuth-level interop. >> >> Thanks, >> >> Eve >> >> On 13 Jun 2012, at 11:19 AM, William Mills wrote: >> >>> On the informational status, that seemed right, but I honestly don't >> know what the correct choice is here. The actual registration happens via >> e-mail I believe, not via this document. >>> >>> Thanks for the feedback! >>> >>> -bill >>> >>> >>> >>> - Original Message - >>>> From: Goix Laurent Walter >>>> To: Peter Saint-Andre ; William Mills >> >>>> Cc: O Auth WG ; Apps Discuss >> >>>> Sent: Wednesday, June 13, 2012 9:44 AM >>>> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>>> >>>> T hank you William for this initiative. >>>> >>>> I had similar concerns than Peter on authn vs authz. >>>> >>>> Under section 4.1.1 I would suggest to use "oauth2-authorize" >> instead >>>> of "oauth2-authenticator", to be consistent with the >>>> "oauth2-token" pattern and with the concepts of the oauth2 >> draft. >>>> >>>> The header of the pages still reference sasl/gss-api and would need to >> be >>>> updated. >>>> >>>> Also, an example and/or use case section could be beneficial, e.g. to >> describe >>>> its usage in an xrd document. Other use cases may be mentioned as well >> probably. >>>> >>>> I have also noticed that your draft is mentioned as >> "informational". >>>> It is indeed your target or only a typo? >>>> >>>> Thanks >>>> walter >>>> >>>>> -Messaggio originale- >>>>> Da: apps-discuss-boun...@ietf.org >> [mailto:apps-discuss-boun...@ietf.org] >>>> Per &
Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions
ified. >> > >> > I'll send a separate mail about that, the current text in the spec is way >> > too unspecific. >> > >> >> -- Mike >> >> >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "> >> Unicode character other than ( %x0-1F / %x7F )>", please send it to me! >> > >> > As noted before, here's an example: >> > <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1> >> > >> > Best regards, Julian >> > ___ >> > 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 > > > This message and any attachment are intended solely for the addressee and may > contain confidential information. If you have received this message in error, > please send it back to me, and immediately delete it. Please do not use, copy > or disclose the information contained in this message or in any attachment. > Any views or opinions expressed by the author of this email do not > necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration.
ation >> Endpoint", >>> however draft-ietf-oauth-v2 defines only an authorization endpoint, a >>> token endpoint, and an access token endpoint. Whence this >>> "authentication endpoint"? Is it just a typo? >>> >>> Also, is the lack of a link type for OAuth2 access token endpoints an >>> oversight? It seems so. >>> >>> You have "Reference: [[this document]]" but I think you want: >>> >>> Reference: draft-ietf-oauth-v2 >>> >>> and >>> >>> Reference: RFC 5849 >>> >>> You can remove the reference for draft-hammer-hostmeta (RFC 6415 has >>> what you need). >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> >>> >>> ___ >>> apps-discuss mailing list >>> apps-disc...@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone >> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla >> conoscenza di queste informazioni sono rigorosamente vietate. Qualora >> abbiate >> ricevuto questo documento per errore siete cortesemente pregati di darne >> immediata comunicazione al mittente e di provvedere alla sua distruzione, >> Grazie. >> >> This e-mail and any attachments is confidential and may contain privileged >> information intended for the addressee(s) only. Dissemination, copying, >> printing >> or use by anybody else is unauthorised. If you are not the intended >> recipient, >> please delete this message and any attachments and advise the sender by >> return >> e-mail, Thanks. >> > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested
I hope to attend in person. Once we know the meeting time slot, I'll be able to confirm one way or the other. Eve On 3 Jun 2012, at 9:09 AM, Torsten Lodderstedt wrote: > I plan to attend. > > regards, > Torsten. > > Am 02.06.2012 09:46, schrieb Hannes Tschofenig: >> Hi all, >> >> I have requested a 2,5 hour slot for the upcoming meeting. >> >> While the next meeting is still a bit away it is nevertheless useful to hear >> * whether you plan to attend the next meeting, and >> * whether you want to present something. >> >> I could imagine that these documents will be discussed: >> * draft-ietf-oauth-dyn-reg >> * draft-ietf-oauth-json-web-token >> * draft-ietf-oauth-jwt-bearer >> * draft-ietf-oauth-revocation >> * draft-ietf-oauth-use-cases >> >> To the draft authors of these docuemnts: Please think about the open issues >> and drop a mail to the list so that we make some progress already before the >> face-to-face meeting. >> >> I am assume that the following documents do not require any discussion time >> at the upcoming IETF meeting anymore: >> * draft-ietf-oauth-assertions >> * draft-ietf-oauth-saml2-bearer >> * draft-ietf-oauth-urn-sub-ns >> * draft-ietf-oauth-v2 >> * draft-ietf-oauth-v2-bearer >> >> Ciao >> Hannes >> >> ___ >> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IIW and OAuth
I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. Some UMAnitarians have suggested proposing an IIW session to collect OAuth AS/RS separation use cases. I'm happy to champion that on the Tuesday if there's interest. Also, we're planning to have an UMA "open meeting" during a couple of Thursday afternoon blocks, if any folks on this list would like to join in. (Thursday is "Yukon day", which is roughly the personal data ecosystem day. I can't recall how it got this moniker.) Eve On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote: > Hi guys, > > I was wondering how many of you will be at the upcoming IIW in Mountain View > (or for some other event). IIW will run from Tuesday (May 1st) to Thursday > (May 3rd). > > I thought it might be good to useful to get together on the Friday after the > IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require brainstorming. > > > Drop me a message if you are able and interested. > > Ciao > Hannes > > PS: Please do not forget to read the Assertion specs so that we can get them > out of the door. > (And thanks to those who have already read them.) > > ___________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
>>> Am 18.04.2012 22:01, schrieb Justin Richer: >>>> Not all implementations in the field that do this are using JWTs as the >>>> tokens. Ours in particular used a random blob with no structured >>>> information in it. The endpoint returned a JSON object. >>>> >>>> -- Justin >>>> >>>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >>>>> Hi all, >>>>> >>>>> is there enough experience in the field with such an interface to >>>>> standardize it? >>>>> >>>>> I would expect such an endpoint to return the same payload, which is >>>>> carried in a JSON Web Token. So once we designed the JSON Web Tokens >>>>> content, designing the AS-PR interface could be the next logical step >>>>> (after the next re-charting). >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> Am 16.04.2012 21:04, schrieb Justin Richer: >>>>>> >>>>>>>> OK, but with SWD and discovery off the table, can this now be >>>>>>>> considered to be within that manageable number instead? >>>>>>> We wanted to keep the # of WG items to approximately 5. Once we finish >>>>>>> some of these items and get them off our plate we could roll new items >>>>>>> onto the plate, theoretically. >>>>>>> >>>>>> >>>>>> That's definitely true going forward, but what I was saying is that the >>>>>> number of items under consideration is now down to 4, with SWD moving to >>>>>> the Apps group. I was proposing that the whole introspection endpoint >>>>>> and general AS-PR connection could be this group's fifth starting >>>>>> document. >>>>>> >>>>>> -- Justin Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Client Registration
Hi Hannes-- That's kind of a cool idea. You're right that it's a "client account" of sorts. At least worth exploring, I'd say, unless a SCIM expert pipes up with a reason why not. Eve On 13 Apr 2012, at 7:36 AM, Hannes Tschofenig wrote: > Hi all, > > at the IETF#83 OAuth working group meeting we had some confusion about the > Dynamic Client Registration and the Simple Web Discovery item. I just > listened to the audio recording again. > > With the ongoing mailing list discussion regarding WebFinger vs. Simple Web > Discovery I hope that folks had a chance to look at the documents again and > so the confusion of some got resolved. > > I believe the proposed new charter item is sufficiently clear with regard to > the scope of the work. Right? > Here is the item again: > " > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG > for consideration as a Proposed Standard > > [Starting point for the work will be > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > ] > " > > Of course there there is a relationship between Simple Web Discovery (or > WebFinger) and the dynamic client registration since the client first needs > to discover the client registration endpoint at the authorization server > before interacting with it. > > Now, one thing that just came to my mind when looking again at > draft-hardjono-oauth-dynreq was the following: Could the Client Registration > Request and Response protocol exchange could become a profile of the SCIM > protocol? In some sense this exchange is nothing else than provisioning an > account at the Authorization Server (along with some meta-data). > > Is this too far fetched? > > Ciao > Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue token for another user
As written in the I-D, the use case does call for person-to-person sharing, which OAuth in its current state doesn't really cover. If you do want to achieve that outcome, User-Managed Access, built on top of OAuth, specializes in it. You can find out more at http://kantarainitiative.org/confluence/display/uma/Home . (We're holding a Twitter #umachat this Wednesday 9-10am PT if you want to deep-dive on UMA one tweet at a time.) Eve On 11 Mar 2012, at 7:10 PM, David Fox wrote: > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8 > > In order to achieve the use case above, how would the client (a.k.a the > resource owner in this case) specify which user to authorize? > > Would the correct approach be to make a request to the Authorization Server > with the grant type set to "client_credentials" and set the scope to > user=user_id (where user_id would be the identifier for the user Bob)? > > -David > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)
If you check out the recording of the UMA webinar from last week, you'll see a demo (starting at about the 33:00 mark) that shows individual user data being accessed according to ACL-type authorization policy settings, with the resource owner able to set these policies and then not have to be online when the requester shows up: http://kantarainitiative.org/confluence/display/uma/Home (As an aside, the UMA spec also provides an extended example that illustrates how scopes can be made interoperable enough to protect photos individually. See http://tools.ietf.org/html/draft-hardjono-oauth-umacore-02, especially Sections 1.4 and 10.) Eve On 19 Dec 2011, at 10:02 AM, George Fletcher wrote: > I would also recommend looking at User-Managed-Access which provides this > kind of layer on top of OAuth2. > > http://kantarainitiative.org/confluence/display/uma/UMA+Explained > > Thanks, > George > > On 12/18/11 12:05 PM, Melvin Carvalho wrote: >> Quick question. I was wondering if OAuth 2.0 can work with access >> control lists. >> >> For example there is a protected resource (e.g. a photo), and I want >> to set it up so that a two or more users (for example a group of >> friends) U1, U2 ... Un will be able to access it after authenticating. >> >> Is this kind of flow possibly with OAuth 2.0, and if so whose >> responsibility is it to maintain the list of agents than can access >> the resource? >> ___ >> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Rechartering
d to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard protocols and > we will see plenty of deployments with a bunch of different OAuth protected > resource servers. Shall this servers all be accessible with a single token? > In my opinion, this would cause security, privacy and/or > scalability/performance problems. To give just the most obvious example, the > target audience of such a token cannot be restricted enough, which may allow > a resource server (or an attacker in control of it) to abuse the token on > other servers. But the current design of the code grant type forces > deployments to use the same token for all services. What is needed from my > point of view is a way to request and issue multiple server-specific access > tokens with a single authorization process. > > I've been advocating this topic for a long time now and I'm still convinced > this is required to really complete the core design. We at Deutsche Telekom > needed and implemented this function on top of the existing core. In my > opinion, a core enhancement would be easier to handle and more powerful. If > others support this topic, I would be willed to submit an I-D describing a > possible solution. > > If we take standards really seriously, then service providers should be given > the opportunity to implement their service by utilizing standard server > implementations. This creates the challenge to find a standardized protocol > between authorization server and resource server to exchange authorization > data. Depending on the token design (self-contained vs. handle) this could be > solved by either standardizing a token format (JWT) or an authorization API. > > Based on the rationale given above, my list is as follows (topics w/o I-D are > marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented in some > places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig : > >> Hi all, >> >> in preparation of the upcoming IETF meeting Barry and I would like to start >> a re-chartering discussion. We both are currently attending the Internet >> Identity Workshop and so we had the chance to solicit input from the >> participants. This should serve as a discussion starter. >> >> Potential future OAuth charter items (in random order): >> >> >> >> 1) Dynamic Client Registration Protocol >> >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >> >> 2) Token Revocation >> >> Available document: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> 3) UMA >> >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >> >> 4) Client Instance Extension >> >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >> >> 5) XML Encoding >> >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >> >> 6) JSON Web Token >> >> Available document: >> http://tools.ietf.org/html/draft-jones-json-web-token-05 >> >> 7) JSON Web Token (JWT) Bearer Profile >> >> Available document: >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >> >> 8) User Experience Extension >> >> Available document: >> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >> >> 9) Request by Reference >> >> Available document: >> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >> >> 10) Simple Web Discovery >> >> Available document: >> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >> >> >> >> We have the following questions: >> >> a) Are you interested in any of the above-listed items? (as a reviewer, >> co-author, implementer, or someone who would like to deploy). It is also >> useful to know if you think that we shouldn't work on a specific item. >> >> b) Are there other items you would like to see the group working on? >> >> Note: In case your document is expired please re-submit it. >> >> Ciao >> Hannes & Barry >> >> ___ >> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback
FWIW, the "Dynamic OAuth Client Registration" proposal made by the User-Managed Access folks: http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00 ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based UMA protocol itself: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt We'd be just as happy to use a JSON-based version of XRD if it can be standardized, and we did do some experimentation with this early on. But because XRD 1.0 is now stable and is straightforward enough to use for our needs, we decided to use it normatively for now. The UMA implementation used by http://smartam.net implements this today and it works fine. Eve On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote: > Hannes, > > None of the current OAuth WG document address discovery in any way, so > clearly there will be no use of XRD. But the OAuth community predating the > IETF had multiple proposals for it. In addition, multiple times on the IETF > OAuth WG list, people have suggested using host-meta and XRD for discovery > purposes. > > The idea that XRD was reused without merit is both misleading and > mean-spirited. Personally, I'm sick of it, especially coming from standards > professionals. > > XRD was largely developed by the same people who worked on host-meta. XRD > predated host-meta and was designed to cover the wider use case. Host-meta > was an important use case when developing XRD in its final few months. It was > done in OASIS out of respect to proper standards process in which the body > that originated a work (XRDS) gets to keep it. > > I challenge anyone to find any faults with the IPR policy or process used to > develop host-meta in OASIS. > > XRD is one of the simplest XML formats I have seen. I bet most of the people > bashing it now have never bothered to read it. At least some of these people > have been personally invited by me to comment on XRD while it was still in > development and chose to dismiss it. > > XRD was designed in a very open process with plenty of community feedback and > it was significantly simplified based on that feedback. In addition, > host-meta further simplifies it by profiling it down, removing some of the > more complex elements like Subject and Alias (which are very useful in other > contexts). XRD is nothing more than a cleaner version of HTML elements > with literally a handful of new elements based on well defined and widely > supported requirements. It's entire semantic meaning is based on the IETF > Link relation registry RFC. > > There is something very disturbing going on these days in how people treat > XML-based formats, especially form OASIS. > > When host-meta's predecessor - side–meta – was originally proposed a few > years ago, Mark Nottingham proposed an XML format not that different from > XRD. There is nothing wrong with JSON taking over as a simpler alternative. I > personally prefer JSON much better. But it would be reckless and counter > productive to ignore a decade of work on XML formats just because it is no > longer cool. Feels like we back in high school. > > If you have technical arguments against host-meta, please share. But if your > objections are based on changing trends, dislike of XML or anything OASIS, > grow up. > > EHL > > > > From: Hannes Tschofenig > Date: Sun, 3 Jul 2011 00:36:29 -0700 > To: Mark Nottingham > Cc: Hannes Tschofenig , "i...@ietf.org IETF" > , Eran Hammer-lahav , oauth WG > > Subject: Re: Second Last Call: (Web Host > Metadata) to Proposed Standard -- feedback > >> I also never really understood why XRD was re-used. >> >> Btw, XRD is not used by any of the current OAuth WG documents, see >> http://datatracker.ietf.org/wg/oauth/ >> >> >> On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: >> >>> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm >>> just scarred by WS-*, but it seems very over-engineered for what it does. I >>> understand that the communities had reasons for using it to leverage an >>> existing user base for their specific user cases, but I don't see any >>> reason to generalise such a beast into a generic mechanism. >> >> > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
I'm interested in learning about all of the above (uh, below). Eve On 24 Jun 2011, at 2:34 PM, Phil Hunt wrote: > Eve, > > Were you just asking about client libraries? Or did you mean some open > source for things like building authorization/token/resource service > end-points? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-06-24, at 2:24 PM, Eran Hammer-Lahav wrote: > >> I maintain the node.js 'mac' module: >> >> https://github.com/hueniverse/node-mac >> or 'npm install mac' >> >> A browser JS lib is available at: >> >> https://sled.com/scripts/mac.js >> >> Both are used in production. >> >> EHL >> >> >>> -Original Message- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>> Of Eve Maler >>> Sent: Friday, June 24, 2011 2:19 PM >>> To: oauth WG >>> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source? >>> >>> Thanks, y'all, for the responses. I've heard from others that a library can >>> end >>> up taking more time to figure out than just coding it fresh because the >>> latter >>> is just that simple, but I suspect this is a YMMV kind of thing. And it >>> seems >>> there's universal agreement that a MAC library would be a very good idea >>> regardless. >>> >>> Eve >>> >>> On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote: >>> >>>> Hi, I notice most open source OAuth2 client/server libraries >>>> implementation is only up to draft 10. >>>> >>>> Here's a quick raw list in case you interested: >>>> https://github.com/teohm/teohm.github.com/wiki/OAuth >>>> >>>> Anyone knows if there is an open source OAuth2 server reference >>>> implementation that reflects the latest draft 16, and unit-tested >>>> against the security considerations in section 10? >>>> >>>> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler wrote: >>>>> Zero response from the other list. Any suggestions from folks here? >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Eve Maler >>>>>> Date: 20 June 2011 4:54:56 PM PDT >>>>>> To: oa...@googlegroups.com >>>>>> Subject: [oauth] Good list of OAuth open source? >>>>>> Reply-To: oa...@googlegroups.com >>>>>> >>>>>> The list at http://oauth.net/code/ seems really random and out of date. >>> Does anyone have a current list of open-source software that supports >>> OAuth, including drafts of 2.0? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Eve >>>>> >>>>> >>>>> Eve Maler http://www.xmlgrrl.com/blog >>>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>>>> >>>>> ___ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> -- >>>> Teo Hui Ming >>>> >>> >>> >>> Eve Maler http://www.xmlgrrl.com/blog >>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>> >>> ___ >>> 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 > > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Thanks, y'all, for the responses. I've heard from others that a library can end up taking more time to figure out than just coding it fresh because the latter is just that simple, but I suspect this is a YMMV kind of thing. And it seems there's universal agreement that a MAC library would be a very good idea regardless. Eve On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote: > Hi, I notice most open source OAuth2 client/server libraries > implementation is only up to draft 10. > > Here's a quick raw list in case you interested: > https://github.com/teohm/teohm.github.com/wiki/OAuth > > Anyone knows if there is an open source OAuth2 server reference > implementation that reflects the latest draft 16, and unit-tested > against the security considerations in section 10? > > On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler wrote: >> Zero response from the other list. Any suggestions from folks here? >> >> Begin forwarded message: >> >>> From: Eve Maler >>> Date: 20 June 2011 4:54:56 PM PDT >>> To: oa...@googlegroups.com >>> Subject: [oauth] Good list of OAuth open source? >>> Reply-To: oa...@googlegroups.com >>> >>> The list at http://oauth.net/code/ seems really random and out of date. >>> Does anyone have a current list of open-source software that supports >>> OAuth, including drafts of 2.0? >>> >>> Thanks, >>> >>> Eve >> >> >> Eve Maler http://www.xmlgrrl.com/blog >> +1 425 345 6756 http://www.twitter.com/xmlgrrl >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Teo Hui Ming > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Zero response from the other list. Any suggestions from folks here? Begin forwarded message: > From: Eve Maler > Date: 20 June 2011 4:54:56 PM PDT > To: oa...@googlegroups.com > Subject: [oauth] Good list of OAuth open source? > Reply-To: oa...@googlegroups.com > > The list at http://oauth.net/code/ seems really random and out of date. Does > anyone have a current list of open-source software that supports OAuth, > including drafts of 2.0? > > Thanks, > > Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Looking for feedback on "client-server OAuth" usage
Folks-- Sorry for the intrusion, but this seemed the community best positioned
to respond to this query. I'm interested to talk to security architects and
application architects in organizations that have informed opinions on the
"client-server" pattern of OAuth as an enterprise web services security
technique, either because:
- You currently use it with full forethought
- You currently see ad-hoc usage of it in your org
- You are considering using it for some use cases
- You have considered and rejected it
Any or all of the 2.0 MAC pattern, 1.0a usage, plain old app-to-app protection,
mobile use cases, etc. are fair game. Feel free to drop me a note at
e...@xmlgrrl.com or ema...@forrester.com, or ping me on Twitter (use the
hashtag #Forr2Legs to catch my attention fastest), or write in here if you like:
http://forr.com/FORRblog_OAuth
Feel free to forward this to folks you know who might be interested to respond.
Thanks in advance,
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Working Group Items?
presently in the charter, and > therefore it can be discussed only in the context of changing the charter. > And so I first wrote this in response to the item that you proposed, which I > think is one step toward what I thought should be done. > > Igor > > Kristoffer Gronowski wrote: >> ... >> IMO there is one item missing and that is to create an optional formal >> interface between the authorization server and the protected resource. >> It could increase the productivity of creating the oauth protected web >> services when the auth server can be treated as an off the shelf piece >> of code. >> Then it would be up to the auth server to also provide an number of >> other extension like the discovery, token revocation and other. > > >> >> > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10
A comment on Mike's comment on the idea of a "resource" parameter... On 24 Nov 2010, at 11:31 PM, Eran Hammer-Lahav wrote: > Thanks Mike! Comments inline. > >> Normative Issues >> >> 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1 "Scope" parameter should be >> paired with >> complimentary "resource" parameter > > I am more inclined to drop 'scope' than to include 'resource'. Scope as > currently defined can easily accommodate resource - we specifically chose > space-delimited to allow URI values. If you want a new parameter, *you* will > have to build consensus. Not wearing my editor hat, I'm -1. Over in UMA-land we've had to solve for this because our use cases anticipate protecting arbitrary resources, not just singular APIs, and because our loosely coupled resource server and authorization server components need to communicate about this stuff in an organized fashion. After many months of discussion, as well as UX and implementation work by various participants, in the last week we finally got consensus around having two parts (resource sets and actions, the latter being a close analogue to today's OAuth scopes) rather than a single flat scope namespace. The degenerate case could be very much like today's common practice, but we believe it handles a lot more use cases. There's still work to do to propagate information in this two-part form throughout the protocol flow (which is what Mike was directly suggesting), but at least we now have a conceptual foundation for doing that. If there is consensus here for adding a parameter, it would make UMA's life easier as we wouldn't have to invent anything weird and nonstandard. :-) See the "Resource Registration" spec link from our Working Drafts page for more info; if there's sufficient interest, we could contribute it as an IETF I-D soonish: http://kantarainitiative.org/confluence/display/uma/Working+Drafts Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)
Hi Hannes, Regarding UMA's "security use cases", indeed we haven't been producing formal use cases in a form that readily maps to what this group is looking for. However, I've reproduced below the comments I sent you privately on your OAuth signature thoughts doc (too late for your IETF submission editing round); they contain specific descriptions and pointers to a major security requirement of UMA that relates to this discussion. Eve - The Alice/Bob/Carol language is a bit distracting. I kept scribbling "authz server" etc. on my copy to make sure I had it straight. Given that you're talking about OAuth specifically, do you think using real OAuth terminology would be okay? - (Nit:) At the bottom of page 2, I couldn't understand "...and in managing a resource that is work delegating access to." - I think there's a threat missing, something like "token replay" (but that doesn't seem quite right). This is where the Alice language is holding me back! If Alice == client, the token might be stolen by a malicious client Eve (or Alice might maliciously give it to Eve to use), then used at Bob as if Eve were Alice. Naming all the threats "token " makes it hard to decide what to call it, but left to my own devices I'd call it "client correlation". OAuth seems to want to put this out of scope, but it's a real problem for UMA, given that our authorization server and resource server might be in different administrative domains. You can see the problem statement here: http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread/cafa098084c7c208/703617741a124124?lnk=gst&q=step+3#703617741a124124 ...and our current (very constrained and signature-free!) solution in Step 3 here: http://mrtopf.clprojects.net/uma/draft-uma-core.html One of the reasons we want to be able to point to/build on an OAuth signing solution is that a short token lifetime isn't very performant/scalable. But we're inclined to leave our simple solution in place as mandatory-to-implement. - Another thing that's probably worth observing is that OAuth thinks of a token as either containing real assertions or being an artifact that can be referenced to get to assertions. But UMA's treatment is entirely consistent too: a token stands for an authorization decision, with all the specifics of assertions/claims pushed exclusively to the Alice/Carol (client/authz server) communication. On 28 Oct 2010, at 4:04 AM, Hannes Tschofenig wrote: > Hey Tim, > > Earlier this year we had discussions around use cases but they did not lead > to more insight. > > There is a document in the draft repository that talks about use cases, > namely > http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ > But it had never gotten a lot of attention on the list. (I don't know why.) > > Efforts to reach out to the Kantara UMA group for more sophisticated uses > cases that motivate some security mechanisms have not produced anything > either. (I believe the reason was that the scenarios focused on the > user-experience aspect rather than on security differences.) > > If you look at the draft that Blaine and I put together recently (see > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/ > ) then you will notice that from a security point of view there is very > little difference between using message signing on the HTTP layer and using > TLS with respect to a certain class of security threats. > > In our recommendation we actually suggest to recommend to go for the HTTP > layer security because we are worried that ***operational*** aspects will go > wrong in deployments. > > While I was convinced initially that looking at the use cases will get us > further on the security questions it actually does not. > > Ciao > Hannes > > PS: Btw, your feedback on the security draft would be of interest to us. > > > On 10/27/10 9:09 PM, "ext Freeman, Tim" wrote: > >> On the face of it, it seems that discussion of whether and how to split the >> document has derailed collection of use cases. If we had consensus on a list >> of use cases, that would mean we have identified the problems we're trying to >> solve. This would still allow slimy political manipulation of the process by >> manipulating the use case list, but that would be progress. It's better to >> have a protocol that solves a politically-defined set of problems than to >> have >> a politically-defined protocol that solves no identified problem. Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Opensource impl yet?
Don't forget this implementation: http://leeloo.smartam.net/ Eve On 12 Oct 2010, at 10:32 PM, David Recordon wrote: > I haven't seen one. Have been trying to keep track of all the implementation > on http://wiki.oauth.net/w/page/OAuth-2. > > > On Tue, Oct 12, 2010 at 9:33 AM, William Mills wrote: > Is there a C/C++ opensource implementation yet I can use for the reference > implementation of the SASL mechanism yet? > > > ___ > 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comparing the JSON Token drafts
e > frameworks, which can lead to confusion. > > · Claim name length: Given that a core goal of both specs is short > tokens, I would propose that we use the shorter reserved claim names. Having > short tokens is especially important when used with mobile browsers, where > URL length restrictions may be severe. (People are always free to use longer > ones in any particular application context if they have a reason to do so.) > > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > · Elliptic curve crypto and longer key lengths: The JWT spec defines > how to use ECC as well as HMAC and RSA. Given ECC’s inclusion in NSA Suite B > and that it has engineering advantages over RSA (shorter key lengths and more > efficient computations), it makes sense that any modern spec incorporating > cryptography allow its use as an option. Likewise, it makes sense for the > spec to define how to use longer key lengths on an optional basis. > > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent some > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > As just one datapoint, Google would have a hard time supporting ECC, since > it's not in the Java core library. We don't use bouncycastle. > > · Unsigned tokens: In some application contexts, it may make sense > to send unsigned tokens if carried in a signed and/or encrypted container or > channel. Allowing for unsigned tokens means that double signing need not > occur. > > That one just confuses me :-) What's the difference between OAuth without > signatures and unsigned tokens? Is the latter not just a more complicated way > of doing the former? > > · Key identification: I agree that having means of identifying and > distributing keys are critical for to end-to-end security of signed tokens. > That’s a separate point from whether the key identification and distribution > mechanisms should be part of the token format specification, or treated > separately. I would advocate that it be treated separately (as was done with > SWTs as well), but am open to discussion on this point. > > · Discovery: Like key distribution, I believe that an agreement on > discovery mechanisms is critical to many use cases. But like key > distribution, I’d like us to take that up in a separate specification, rather > than tightly binding the use of JSON tokens to a particular discovery > mechanism. > > > > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, key > rotation, etc. To actually reap the benefits of key rotation, though, we need > to say how to find out what the currently-used key is. If we don't, then a > lot of the potential advantage of using public keys evaporates. I'm concerned > that, lacking the discovery spec, developers will start hard-coding keys into > their servers, and we'll end up in a situation where we can't rotate keys > when Something Bad happens. > > · Envelope structure: Dirk’s draft proposes that the signed content > be wrapped in a particular kind of envelope. Among other things, this > envelope can help prevent a token from being repurposed from one context to > another, by having a clear (and cryptographically verified) declaration that > “This is a JSON token”. I understand this motivation and am open to > discussions on how to best achieve it, while still providing as little > mechanism as possible (but no less J). > > Well, you've seen my proposal on how to achieve it :-), but I'm also open to > better ways, if someone comes up with one... > > Dirk. > > > Dirk, and others, please jump in! > > > -- Mike > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Basic signature support in the core specification
It seems like you figured it out pretty quickly, given the message you sent immediately after. :-) Referencing another spec from the core spec using normative text is effectively "including it by reference". I meant that I'm sympathetic (+1) to signaling in core OAuth that signatures are to be considered an integral part of it, and that if it makes sense to do so by pointing to a spec module that is pointable-to by other specs that are not OAuth, that's fine (call it a soft -1 to including the signature details directly in the core OAuth spec). Eve On 24 Sep 2010, at 10:39 PM, Dick Hardt wrote: > wrt. developers knowing what they need => I think the AS / PR will tell > developers if they need to use signatures, or if they need to use HTTPS, or > if they need to use assertions. > > Sorry for including more than one topic in my email :: my main point was that > I was confused by what Eve was proposing. > > -- Dick > > > On 2010-09-24, at 7:23 PM, Eran Hammer-Lahav wrote: > >> Most developers don’t know if they need signatures! By putting them >> elsewhere we will be promoting the bearer token approve as the default >> choice and that’s unacceptable to me. It is promoting a specific security >> compromise (for developer ease) that is far from industry consensus. >> >> I can make the same arguments about assertions. Or any single profile. Or >> any client credentials type. The bits that are in are based solely on a team >> effort in trying to accommodate as many people as possible. Seems like those >> opposed signatures got everything they want, don’t really care about others, >> and are ready to call it a day. >> >> EHL >> >> >> On 9/24/10 5:20 PM, "Dick Hardt" wrote: >> >> That's a confusing answer Eve. Is it in the spec or pointed to from the spec? >> >> I think there is consensus that there are enough use cases that signatures >> need to be spec'ed -- the question is if the signature spec is in core or a >> separate spec. >> >> For people that don't need signatures, having them separate keeps the core >> spec simpler. Having a separate spec enables other groups to reuse the >> signature mechanism without confusing their readers with the rest of the >> OAuth spec. >> >> On 2010-09-24, at 1:37 PM, Eve Maler wrote: >> >> > +1 for signature support in the core spec (which may look like normative >> > pointers out to a separate spec module if it turns out there's wider usage >> > for that module beyond OAuth). >> > >> > Eve >> > >> > On 23 Sep 2010, at 6:43 PM, Eran Hammer-Lahav wrote: >> > >> >> Since much of this recent debate was done off list, I'd like to ask people >> >> to simply express their support or objection to including a basic >> >> signature >> >> feature in the core spec, in line with the 1.0a signature approach. >> >> >> >> This is not a vote, just taking the temperature of the group. >> >> >> >> EHL >> >> >> >> _______ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > Eve Maler http://www.xmlgrrl.com/blog >> > +1 425 345 6756 http://www.twitter.com/xmlgrrl >> > >> > ___ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Basic signature support in the core specification
+1 for signature support in the core spec (which may look like normative pointers out to a separate spec module if it turns out there's wider usage for that module beyond OAuth). Eve On 23 Sep 2010, at 6:43 PM, Eran Hammer-Lahav wrote: > Since much of this recent debate was done off list, I'd like to ask people > to simply express their support or objection to including a basic signature > feature in the core spec, in line with the 1.0a signature approach. > > This is not a vote, just taking the temperature of the group. > > EHL > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Rechartering
Dynamic authz server discovery and client registration would be needed in OAuth-based identity management. But I would submit that they're needed even apart from it (since I've got that need), and so should be specified modularly, with the identity management piece pointing to it (if it wants to). I've gotten strong interest in taking forward the dynamic client reg I-D as a work item from my co-authors and also some others who need to solve for native-app flows. So we (with Maciej Machulak as ringleader) can speak up for discovery/registration if that suits the group. (I'm not sure if discovery should be a separate module; I'm inclined to think it should be all together.) Eve On 13 Sep 2010, at 7:31 AM, Christian Scholz wrote: > Hi! > > 2010/9/12 David Recordon > I'd like to see us finish Core before considering re-chartering. :) > > But to your original question. I'm interested in the UX extension (said I'd > edit), device flow (said I'd edit), and the OpenID Connect work which > encompasses dynamic registration and likely artifact binding (also editing > but outside of the IETF). > > As we submitted the draft about dynamic registration I am wondering if we can > somehow join our two. Is http://openidconnect.com/ still recent? > We (coming from UMA) had some additional requirements like also sending some > metadata information from the client to the server (as you'd normally do with > manual registration). We also would probably prefer having a separate spec we > can point to for registration (probably the same for discovery). > > best regards, > > Christian > > -- > Christian Scholz, COM.lounge GmbH, tel. +49 241 400 730 0, > http://comlounge.net > Blog: http://mrtopf.de/blog, Twitter: http://twitter.com/mrtopf > > Podcasts: > Der OpenWeb-Podcast (http://openwebpodcast.de) > Data Without Borders (http://datawithoutborders.net) > Politisches: http://politfunk.de/ > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposal for OAuth dynamic client registration
Great comments; thanks to Christian for responding. To answer just a couple of more points that I don't think got addressed yet: Yes, we would very much like for dynamic client registration to become a work item of this group. (Do we need to take any steps other than stating so in this email?) And, I've written to this list a couple of times in the past, describing ways in which UMA builds on top of OAuth (it's basically a series of profiles and extensions, any of which I'm willing to believe might have value to a wider community on its own), but it seems like a summary at this juncture would be a good idea. If OAuth has two steps, "get a token" and "use a token", UMA has three, adding one at the beginning: - Step 1: trust a token: Authorizing user introduces host to authorization manager as an OAuth client of it. The host and AM need to acquaint themselves with each other in the context of this user to support the user's setting of policies at the AM that will govern the giving out of requester access tokens for the host's protected resources later. The specifics involve the host actually getting its own access token that it can use at a host-specific set of endpoints at the AM (it's basically an embedded instance of OAuth). As necessary, the dynamic client registration stuff comes in. - Step 2: get a token: The requester approaches a protected resource, learns where to go to get an access token, and sets about trying to get it in mostly a normal fashion (engaging in dynamic client registration as necessary). What UMA adds on top is that the AM can ask the requester to produce "claims" in support of proving its suitability for getting the token. If the authorizing user had set policies that could be applied unilaterally in token issuance, great, but if the user had set policies that require the requester to (say) promise to adhere to the user's licensing terms, that can be provided in a claim. (The mechanism is simple so far, but the implications are powerful... We've been exploring legal considerations of authorizing access by fully autonomous parties.) - Step 3: use a token: Requester wields token at host to get access. What UMA adds on top is the host's ability to talk to the AM on a back channel to validate that token, to support minimal host implementations and fully dynamic host deployments. We're still in the process of defining (and in some cases redefining) the various protocol bits, and welcome input and engagement from others if the use cases we're solving for float your boat. If you want to see a full experimental implementation (soon to be open-sourced, I understand) in action, I-D coauthor Maciej and his crew are documenting their work at http://smartjisc.wordpress.com/. Eve On 11 Aug 2010, at 3:40 AM, Torsten Lodderstedt wrote: > Eve, > > thank you for writting this document. I consider it a good starting point for > a discussion about client registration and discovery. Will you propose this > as a WG item? > > My comments & questions: > > You propose a host-meta based discovery of the registration endpoint on the > authz server. Could this mechanism be used for discovering all AS endpoints, > e.g. tokens and end-user authorization? > > How is a UMA requestor envisioned to discover the auth server? > > I think host-meta based client discovery could be to limited since it does > not allow (at least in my understanding) to serve different clients (or their > home web apps) on the same host. What about using JRD or XRD? This would > allow for a client-URL-related discovery. > > What means for authentication a client against its home web app. do you > envision? > > regards, > Torsten. > > Am 10.08.2010 um 21:31 schrieb Eve Maler : > >> Folks-- The UMA group has produced the following I-D as input to the OAuth >> discovery/registration/binding discussion. We wanted to set forth our >> requirements (knowing that there may be other requirements from the wider >> community) and propose some solutions that meet them. If further discussion >> seems to warrant an updating of this draft, we're happy to do that. (If you >> have interest in getting involved in UMA-specific work, feel free to drop me >> a note.) >> >> Eve >> >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: 10 August 2010 12:23:59 PM PDT >>> To: e...@xmlgrrl.com >>> Cc: c...@comlounge.net, m.p.machu...@ncl.ac.uk >>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 >>> >>> >>> A new version of I-D, draft-o
[OAUTH-WG] Proposal for OAuth dynamic client registration
Folks-- The UMA group has produced the following I-D as input to the OAuth discovery/registration/binding discussion. We wanted to set forth our requirements (knowing that there may be other requirements from the wider community) and propose some solutions that meet them. If further discussion seems to warrant an updating of this draft, we're happy to do that. (If you have interest in getting involved in UMA-specific work, feel free to drop me a note.) Eve http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt Begin forwarded message: > From: IETF I-D Submission Tool > Date: 10 August 2010 12:23:59 PM PDT > To: e...@xmlgrrl.com > Cc: c...@comlounge.net, m.p.machu...@ncl.ac.uk > Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 > > > A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully > submitted by Eve Maler and posted to the IETF repository. > > Filename: draft-oauth-dyn-reg-v1 > Revision: 00 > Title: OAuth Dynamic Client Registration Protocol > Creation_date: 2010-08-10 > WG ID: Independent Submission > Number_of_pages: 20 > > Abstract: > This specification proposes an OAuth Dynamic Client Registration > protocol. > > > > The IETF Secretariat. > > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] resource server id needed?
The "scope flow" is intended to carry this information, and the authz manager/server compares the requested scope to a known mapping of protected resources to resource servers. (We're still working out details, and also trying to keep up with the changes to the OAuth2 substrate...) Eve On 3 Aug 2010, at 7:04 AM, Torsten Lodderstedt wrote: > I mean address as in "uniquely label". > > Based on your explanation I assume you address resources instead of resource > servers. Correct? What parameter of the end-user authorization flow is used > to indicate the resource URL to the authz server. The scope? > > regards, > Torsten. > > > > Am 02.08.2010 um 02:16 schrieb Eve Maler : > >> I'm not sure if you mean "address" as in "handle", or "address" as in >> "uniquely label", but... UMA's first step involves a user-delegated >> introduction of a resource server to an authorization server as a special >> kind of client of it, using an OAuth2 web server flow with dynamic client >> registration as necessary. As part of this overall process, the resource >> server can tell the authorization server specifically which resource URLs >> are protected thereby (one way to do this is to wield its just-acquired >> access token at a protected resource registration endpoint at the authz >> server). Access tokens given to requesters (the real end-of-the-line >> clients) for accessing these resources are currently assumed to be given out >> on a per-resource-server basis, and each resource is uniquely associated >> with a single resource server and uniquely protected by a single >> authorization server, so there is no ambiguity. I suppose a resource server >> namespace could allow for higher-order aggregation as discussed below but I >> would personally prefer baby steps when it comes to the amount of dynamicism >> we're already assuming... >> >> If you want to follow along with the UMA work, we have floated a number of >> spec drafts for these portions of our Step 1, and should shortly (within a >> day or so) have a more fleshed-out resource registration draft ready. We're >> not just cataloguing the resource URLs, but also the possible methods for >> accessing them; our assumption to date, as noted previously on this list, >> has been that the simple set of HTTP methods can get everyone really far -- >> but mindful of the need in OAuth-land for arbitrary "space-delimited list of >> strings" for scope, the current nascent draft allows for this. >> >> Eve >> >> On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote: >> >>> Eve, >>> >>> how does UMA plan to address resource servers during the OAuth end-user >>> authorization process? >>> >>> regards, >>> Torsten. >>> >>> Am 29.07.2010 02:37, schrieb Eve Maler: >>>> >>>> Belatedly... Sorry if I sound like a broken record on this, but: Most of >>>> UMA's use involve letting a user introduce their various hosts >>>> (UMA-flavored resource servers) to their single chosen "authorization >>>> manager" (UMA-flavored authorization server), by treating the former as a >>>> dynamically introduced OAuth client of the latter. This sounds an awful >>>> lot like the question originally posed in this thread. We have exactly the >>>> problem of figuring out how the host can tell the AM what resources the AM >>>> should be protecting and what can be done to them, which we've begun to >>>> solve with what we're calling a "resource registration API" (RRAPI). >>>> >>>> (BTW, we're also working on an I-D to submit here that proposes a solution >>>> for discovery/dynamic registration that meets our needs. Hoping it can >>>> feed into Eran's discovery work.) >>>> >>>> Eve >>>> >>>> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: >>>> >>>>> thanks for sharing your thoughts. >>>>> >>>>> Differentiating resource servers by using different end-user >>>>> authorization endpoint URLs is an option. I dont't know how this will >>>>> work in conjunction with discovery, especially since this differentiation >>>>> might by required on other endpoints, too. For example, if a client wants >>>>> to obtain an access token for the end-user's credentials, it has t
Re: [OAUTH-WG] resource server id needed?
I'm not sure if you mean "address" as in "handle", or "address" as in "uniquely label", but... UMA's first step involves a user-delegated introduction of a resource server to an authorization server as a special kind of client of it, using an OAuth2 web server flow with dynamic client registration as necessary. As part of this overall process, the resource server can tell the authorization server specifically which resource URLs are protected thereby (one way to do this is to wield its just-acquired access token at a protected resource registration endpoint at the authz server). Access tokens given to requesters (the real end-of-the-line clients) for accessing these resources are currently assumed to be given out on a per-resource-server basis, and each resource is uniquely associated with a single resource server and uniquely protected by a single authorization server, so there is no ambiguity. I suppose a resource server namespace could allow for higher-order aggregation as discussed below but I would personally prefer baby steps when it comes to the amount of dynamicism we're already assuming... If you want to follow along with the UMA work, we have floated a number of spec drafts for these portions of our Step 1, and should shortly (within a day or so) have a more fleshed-out resource registration draft ready. We're not just cataloguing the resource URLs, but also the possible methods for accessing them; our assumption to date, as noted previously on this list, has been that the simple set of HTTP methods can get everyone really far -- but mindful of the need in OAuth-land for arbitrary "space-delimited list of strings" for scope, the current nascent draft allows for this. Eve On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote: > Eve, > > how does UMA plan to address resource servers during the OAuth end-user > authorization process? > > regards, > Torsten. > > Am 29.07.2010 02:37, schrieb Eve Maler: >> >> Belatedly... Sorry if I sound like a broken record on this, but: Most of >> UMA's use involve letting a user introduce their various hosts (UMA-flavored >> resource servers) to their single chosen "authorization manager" >> (UMA-flavored authorization server), by treating the former as a dynamically >> introduced OAuth client of the latter. This sounds an awful lot like the >> question originally posed in this thread. We have exactly the problem of >> figuring out how the host can tell the AM what resources the AM should be >> protecting and what can be done to them, which we've begun to solve with >> what we're calling a "resource registration API" (RRAPI). >> >> (BTW, we're also working on an I-D to submit here that proposes a solution >> for discovery/dynamic registration that meets our needs. Hoping it can feed >> into Eran's discovery work.) >> >> Eve >> >> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: >> >>> thanks for sharing your thoughts. >>> >>> Differentiating resource servers by using different end-user authorization >>> endpoint URLs is an option. I dont't know how this will work in conjunction >>> with discovery, especially since this differentiation might by required on >>> other endpoints, too. For example, if a client wants to obtain an access >>> token for the end-user's credentials, it has to identify the resource >>> server also on the tokens endpoint. There might be additional endpoint for >>> other flows with similar requirements, e.g. the device flow. >>> >>> Based on your proposal, a derived solution could be to define a standard >>> parameter "resourceserver" and to state how clients should use this >>> parameter on the different endpoints. On the coding level, there would be >>> no difference to your proposal :-) But the client would be able to >>> construct such a URL on its own. >>> >>> Authorizing access for different resource servers is indeed an issue for >>> me. How would you propose to add the namespace? Shall the scope obtained >>> from the resource server already contain such a namespace are shall there >>> be a rule to construct such namespaced-ed scopes in the spec? >>> >>> regards, >>> Torsten. >>> >>> Am 25.07.2010 19:11, schrieb Andrew Arnott: >>>> >>>> It seems to me that if one auth server can create tokens for a diverse set >>>> of resource servers, then why not have different user authorization >>>> endpoint URLs for each type
Re: [OAUTH-WG] resource server id needed?
issue. But the consequence is that authz server, resource servers and >> clients are tight together. >> >> Let me ask you one question: Why are we working together towards a standard >> protocol? I can tell you my expectations: I hope there will be broad support >> not only by libraries, but also by ready-to-use services and clients, so we >> could integrate such services into our deployment easily. Moreover, I would >> like to see OAuth to be included in application/service protocols like >> PortableContacts, SIP, WebDAV, IMAP, ... >> >> So what if I would like to use standard clients to access our services? >> Using scopes for specifying resource server id's in this case is also simple >> - if you take an isolated view. But since scopes may be used to specifiy a >> lot of other things, like resources, permissions, and durations, handling >> w/o a more detailed spec will in practice be impossible. >> >> Suppose a WebDAV service for media data access. Any WebDAV client knows the >> WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, POST, >> DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to >> configure the client with the URL of my personal web storage. To start with >> let's assume, scopes are used to designate resource servers only. So the >> server's scope could be "webstorage". >> >>WWW-Authenticate OAuth realm='webstorage' scope="webstorage" >> >> The client could just pass this parameter to the authz server and everything >> is fine. >> >> On the next level, let's assume the (future) WebDAV standard with >> OAuth-support uses one permission per method type. So the full scope could >> be as follows: >> >>WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET >> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY >> webstorage:MOVE" >> >> Passing this scope w/o any unmodified to the authz server is not an issue. >> But this implies the client asks for full access to the users media storage. >> Since our client is a gallery application, it requires the "GET" permission >> only. How does the client know which of the scope values to pick for the >> end-user authorization process? It must somehow select "webstorage:GET". >> >> But how? >> >> In my personal opinion, clients should be enabled to interpret, combine and >> even create scopes. And yes, this should go to the core of the spec. >> >> 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 >> > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth & Protected feeds
nd > Location: http://cliqset.com/callback?code=myrandomcode123 > > 3) Subscription has been authorized. ToS has been acknowledged. Compete. > > The consumer is able to activate the access_token by confirming the > code provided in the redirect. > > This flow offers what we feel are several significant advantages over > the hybrid approach. > > 1) Redirection becomes optional and is only required when the > precondition_uri is defined by the provider in the access token > response. > > 2) For providers who require TOS acknowledgement, it enables > additional flexibility in how they go about it. For example, if a > provider only requires TOS acknowledgement on the initial subscription > request by a given user, subsequent requests will not provide a > precondition_uri. > > 3) It is also worth exploring this flow as a suitable and more > flexible alternative to the traditional Web Server flow. > > > Questions? Comments? Suggestions? > > > -- > darren bounds > dar...@cliqset.com > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] "access grant" terminology
How about "approval", as in delegation approval or association approval (since the resource owner is approving or consenting to the association of these two services on the owner's behalf for delegated access purposes, with specific tokens later representing specific access authorizations)? Eve On 11 Jul 2010, at 10:26 PM, William Mills wrote: > I think "access credential" is better that either of those. Using > "grant" as a noun is a somewhat obscure usage, a la "land grant", which > I think of more as the deed to a property. > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >> On Behalf Of Eran Hammer-Lahav >> Sent: Saturday, July 10, 2010 8:04 PM >> To: Brian Eaton; OAuth WG >> Subject: Re: [OAUTH-WG] "access grant" terminology >> >> >> >> >> On 7/10/10 7:46 PM, "Brian Eaton" wrote: >> >>> The term "access grant" in the -09 spec is a bit odd. Normally >>> "access grant" or "permission grant" would refer to a >> specific policy >>> decision made by a resource owner. >>> >>> But that's not how the -09 spec uses the term. The -09 >> spec refers to >>> authorization codes and assertions as "access grants". >> Again, that's >>> weird. Normally an assertion would be referred to as a >> "credential", >>> not a grant. >> >> Access grant is something that represents the decision made >> by the resource owner. If the resource owner approves access, >> it is represented by a authorization code. If the resource >> owner shares its password, it is equivalent to unlimited access grant. >> >> I coined the term based on common language, not on any >> existing terminology. >> If there is a real conflict here, I am happy to consider >> another term, but it doesn't sound like this is the case, or >> that the term is used against its meaning. >> >>> I think the term "authorization credential" might be a >> better fit than >>> "access grant". >>> >>> It certainly describes the purpose of the authorization >> code and the >>> assertion. And the term "credential" is normally used to describe >>> things that need to be verified and protected. >> >> I think authorization credential is going to confuse most >> readers. The spec refers to credentials almost exclusively >> when dealing with identifier and password (client, end-user), >> or as a general term for client authentication. >> Authorization is specific to the end-user authorization >> endpoint and will be confusing when used with assertions and >> other grant types. >> >> So I'm open to other ideas but not this one. >> >> Note that since this term impacts the name of the current 'grant_type' >> parameter, changing it means code changes. >> >> If anyone has a last minute idea please share (or if you are >> happy with the current grant type). I expect it to be >> annoying to change once -10 is stable for 4 weeks. >> >> 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 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] POLL: Are you going to Maastricht?
D. On 8 Jul 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 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] What to do about 'realm'
+1. James states two important requirements (don't stand in the way of dynamic config, provide end-user authz endpoint at a minimum) we need to meet, whatever we pick. Eve On 11 Jul 2010, at 6:12 AM, Manger, James H wrote: > Brian, > >> Or even just: >> >> WWW-Authenticate: OAuth2 >> >> Seriously. > > I seriously hope not. > It gives no chance for a client to work with a service without being > pre-configured with a whole lot of service-specific knowledge -- in addition > to an app-id/password. > > I don't think a realm parameter adds much value to a "WWW-Auth.: OAuth2" > header, other than complying with RFC2617. The header does need to provide an > end-user authorization endpoint. Ideally, that one URI would be sufficient > for the protocol to succeed (though currently you need to separately provide > a token endpoint as well). > > -- > James Manger > _______ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Partially standardized format for access tokens?
This is exactly the direction UMA is headed (as George knows :-), since we *are* trying to solve for "unmooring" authorization servers and resource servers -- which we call authorization managers and hosts. The absolute simplest thing to do is hand out tokens that are essentially artifacts that the host must carry over and validate at the AM (I think Dick was calling these "identifiers" but I'm coming to like "artifact"). But by then, in our case, the host and AM have already met in the context of the user who controls the protected resource in question, and in fact the host has gotten an access token to use at the AM's token validation endpoint so it already knows where to go to validate. Thus, the artifact could be an opaque string. There are other aspects to the host-specific API at the AM that become handy/necessary when you have to build in this kind of dynamic association. For example, the host needs to tell the AM what resources it's protecting on behalf of this user; we're fleshing out that API now, but for now it's just POSTing a complete JSON structure (wielding its access token to do so). And I believe it's possible to solve some scoping interop this way too, though we're not there yet by a long shot. Would love to have folks interested in these use cases come on over to the UMA WG and share their thoughts: http://kantarainitiative.org/confluence/display/uma/Home Eve On 4 Jun 2010, at 7:06 AM, George Fletcher wrote: > +1 to some standardization to the token > > The URI would also allow for discovery and the ability for the provider to > define an endpoint in the XRD for the URI that allows "dumb mode" token > validation. This way, even if the resource owner doesn't know how to "crack" > the token locally, they could ask the provider to do it for them. > > Thanks, > George > > On 6/4/10 9:37 AM, Andrew Arnott wrote: >> >> Having just implemented OAuth 2.0 web server flow, it was great to be able >> to issue an "opaque" access token to the client. This access token is in an >> encrypted format that only the resource server understands. I feel pretty >> good about this approach as it lends to high security and tokens that only >> the client needs to store (or not at all). >> >> But I'm wondering about the resource server that trusts multiple auth >> servers, which each have their own access token format. Without even a >> standardized way for an access token to express what format it is in, a >> resource server may have to just try decoding the token each known way until >> one "works". >> >> Proposal: perhaps the access token can be mostly opaque, but not quite. For >> instance: >> The access token is in the format: format=URI&opaquevalue >> Where URI is an arbitrary URI assigned by the auth server to assist the >> resource server in interpreting the opaquevalue part of the token. >> >> Feedback? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> >> ___ >> 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 Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible
On 16 May 2010, at 3:52 PM, Dick Hardt wrote: >> Comment(by e...@…): >> >> (I agree the spec is getting pretty long. I wonder if it's possible to do >> some factoring-out of common text, e.g. regarding common features of >> flows, to mitigate this. The length is actually making me waver a bit on >> my previously shared opinion about including all the currently known flows >> into the core protocol document...) > > IMHO: Reading one long document is better than reading two or more shorter > documents that combined are the same size or longer. I think the current > factoring in the document lets someone read only the flows they need. If need > be, we could clarify that in the copy. I had that in WRAP. Actually, reading V2-05 carefully yesterday, I found that it had indeed already factored out everything that could be, and that it's pretty much the right length and organization for its current purpose. So never mind. :) Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Scope - Coming to a Consensus
On 30 Apr 2010, at 11:00 PM, Torsten Lodderstedt wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >> wrote: >> >>> In my opinion, automatic discovery on scope values is as valuable or not >>> valuable as automatic discovery for a service API. I would like to echo one >>> of my postings: >>> >>> A scope defines the set of permissions a client asks for and that becomes >>> associated with tokens. I don't see the need (and a way) for automatic scope >>> discovery. In my opinion, scopes are part of the API documentation of a >>> particular resource server. So if someone implements a client, it needs to >>> consider the different scopes this client needs the end users authorization >>> for. If the resource server implements a OAuth2-based standard API (e.g. for >>> contact management or e-Mail), a client might be interoperable (in terms of >>> scopes) among the resource servers implementing this standard. >>> >> Not sure I understand, are you saying that for a standard API, like >> IMAP for example, there should be a standard scope (or set of scopes)? >> > > Yes, that's what I said. > > Scopes (~permissions) should be defined allong with the corresponding API. So > developers should know upfront > which scope is required to perform a particular action. For example, > "uploading documents requires scope 'upload'". > The same holds for IMAP. Depending on the IMAP feature set you want to use > there could be plenty of scopes, > ranging from "read users INBOX" to sharing scenarios, where users have access > to other users IMAP folders. This makes a ton of sense. It's one of the reasons that, in UMA, we tried to specify a generic way of expressing scope that naturally and closely matches a resource-oriented (RESTful) API: resource + HTTP method is a reliable shorthand for an access feature. For read and write and even delete permissions on (say) identity data accessed by URL, it's pretty much all the expressiveness you need, and ideally the same documentation easily covers both features and scopes. For any API that's more "compressed" (e.g. one complex endpoint for many operations), it doesn't really help. Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)
In UMA, we've got use cases for "person-to-service" sharing that can act much like the user-delegated OAuth patterns of today (essentially introducing two services to interact on your own behalf), and also use cases for "person-to-person" sharing that involve a "separate resource owner", hence our interest in the autonomous client pattern or a variant thereof. We allow the original resource owner (we call them an authorizing user) to set policies asynchronously at the authorization manager (a sort of enhanced/user-centric authz server) that govern whether a requesting party can ultimately get a token. So in our case, this is how the resource owner gives consent outside the flow. (BTW, the word "ownership" gets tricky in talking about resource access and other "property rights", which are famously described as a "bundle of sticks" to show that different parties might have different subsets of rights. E.g., in some UMA use cases, the authorizing user obviously has the right to throttle or audit who can see certain data, but they don't have the right to actually set the value of that data. Reputation data, such as a credit score or a third-party certification, is a classic example. It's hard to describe the data subject in this case as a total "resource owner"...) Eve On 26 Apr 2010, at 2:17 PM, Chuck Mortimore wrote: > +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 specifically > related to Eve’s comment below that suggests to me that the autonomous 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 case? > 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 resource 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 > March 21, and he agreed with my suggested fix at the time.) > > > > Eve > > > > Eve Maler > > e...@xmlgrrl.com > > http://www.xmlgrrl.com/blog > > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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 > March 21, and he agreed with my suggested fix at the time.) > > Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 'Scope' parameter proposal
I'm getting whiplash. :) Some of us are working on UMA implementations based on the ever-changing OAuth substrate, and just discussed being glad we could reuse OAuth's advertisement of these two endpoints rather than inventing our own mechanism. If it goes, I guess we'll have to go back to defining a way to indicate it in Authz Manager (~AS) hostmeta so that the Host (~Resource Server) can pick it up and tell the Requester (~Client) where to go. FWIW, Eve On 22 Apr 2010, at 12:35 PM, Brian Eaton wrote: > On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav > wrote: >> If we are not going to enable a client to access a protected resource hosted >> by an unfamiliar >> server, we need to stop pretending this (alone) is about interop. In other >> words, if we take >> this approach we are mandating paperwork to make the protocol work, at least >> based >> on this single specification. We can also drop advertising the authorization >> and token >> endpoints in a 401 or really *any* parameter in a WWW-Authenticate response. > > I think dropping the advertisements is the right thing to do. > > I'm hopeful that either PoCo or the IMAP SASL/OAuth work ends up > showing how automatic interop is possible. > > But I'd hate to have OAuth2 recommend something that doesn't actually work. > > Cheers, > Brian > ___________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue: 'username' parameter proposal
Thanks! On 21 Apr 2010, at 5:12 PM, Eran Hammer-Lahav wrote: > This is part of the delegation flows so username should be just fine… > > EHL > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve > Maler > Sent: Wednesday, April 21, 2010 4:43 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal > > 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 > March 21, and he agreed with my suggested fix at the time.) > > Eve > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue: 'username' parameter proposal
as client sites often have long-lived >> cookies and may only be visited by one user on a shared computer. >> >> Right now client site has no way to ask for a token for User 1, and end >> result will be that User 1 starts seeing User 2's data. >> >> On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav >> wrote: >> How can they both be logged in? I have never seen a case where two users can >> be both logged into to the same service at the same time... >> >> EHL >> >> >> >> On 4/19/10 8:33 AM, "Evan Gilbert" wrote: >> >> More details on this enhancement. >> >> Goal: Make sure you get an access token for the right user in immediate mode. >> >> Use case where we have problems if we don't have username parameter: >> Bob is logged into a web site as b...@idp.com. >> Mary (his wife) is logged into IDP on the same computer as m...@idp.com >> A request is made to get an access token via the User-Agent flow in >> immediate mode (or with any redirect without prompting the user) >> -ob now has an access token for Mary and (posts activities, schedules >> events, gets contacts) as Mary >> Hilarity ensues >> >> Secondary goal: Provide a hint for non-immediate mode >> >> On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav >> wrote: >> Evan Gilbert proposed a 'username' request parameter to allow the client to >> limit the end user to authenticate using the provided authorization server >> identifier. The proposal has not been discussed or supported by others, and >> has not received a security review. >> >> Proposal: Obtain further discussion and support from others, as well as a >> security review of the proposal. Otherwise, do nothing. >> >> 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/oauth Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 'Scope' parameter proposal
READ, an unauthenticated PUT on the resource could return the scope > > URI for WRITE. What if you want to both do READs and WRITEs? There may > > be another scope that is READ/WRITE. READ and WRITE are pretty common > > capabilities, but one can imagine much more complex capabilities at > > resources. > > A failed GET will return scope=read and a failed PUT will return scope=write. > The server can issue an access token with: > > scope=read > scope=write > scope=read,write > > The last can be used for both. In other words, there should not be a > read_write scope, instead, the token should have two scopes. > > > The exact semantics to the resource are likely going to very contextual. > > Yes, and this can get very complicated if people want an extremely granular > way of doing permissions. For example, if you want to issue a token that can > read contacts and write email, you will need to define a bigger set: > email_read, email_write, contacts_read, contacts_write. On the other hand, if > a write access is for all authorized resources, you need: email, contacts, > read, write. > > > Given that, returning a single scope value if that is all that makes sense > > to the > > resource will likely address many use cases. > > This is true when looking at a single resource. > > 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 Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] new co-chair
Thanks -- and best wishes in their new/old/continuing roles -- to all of Peter, Hannes, and Blaine! Eve On 25 Mar 2010, at 11:03 AM, Peter Saint-Andre wrote: > > > As you know, I have been named co-director of the Applications Area and > therefore cannot continue serving as co-chair of the OAuth WG. Lisa > Dusseault (outgoing AD) and I (incoming AD) decided that the best way to > ensure continuity would be to promote Hannes Tschofenig from technical > advisor to co-chair. I'd like to thank Hannes for taking on this role, > and I look forward to working with him, Blaine, and the rest of the > group to make this effort a success (yes, I will remain quite involved > in the WG as area director!). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] First draft of OAuth 2.0
I might be interested too; agree that it's not core to this group. Eve On 23 Mar 2010, at 5:15 PM, Chuck Mortimore wrote: > Outside the scope of what this WG should be tackling in the core spec IMO, > but I’d be interested in working on a profile. There is a lot of this > use-case being done in an ad-hoc manner on my platform. > > -cmort > > > On 3/23/10 11:17 AM, "Paul Madsen" wrote: > > Separate from the Client trading a SAML assertion for an Access Token as > in this flow, we are interested in defining how a Client might use SAML > SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid). > > Anybody else interested? > > paul Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] First draft of OAuth 2.0
On 24 Mar 2010, at 9:54 AM, Hans Granqvist wrote: > On Tue, Mar 23, 2010 at 9:44 PM, Dick Hardt wrote: >> ... >> By keeping all profiles in one document, someone easily understands the >> different applications of the technology, and when a different use case >> comes up, they know it is available rather than having to look at a >> different document. > > Yes. One doc rules since the spec + its delta changes are immediately obvious. > > Multiple docs lead to unnecessary restating of facts, potential > redefinitions of terms, versioning and feature creep clashes, visual > hiding of complexity, scopes, etc. + you never know if you have the > whole set of docs. Think WS-*. On reflection, I agree (having contributed to the SAML proliferation-of-specs problem). Any profiles that meet some threshold of interest -- say, more than one party asking for it -- and that are known prior to final publication would be good to include in one package. There are editing, review, and approval overhead costs for every separate spec that this group itself publishes. But it should also be clear how others can produce spinoff profile specs. SAML offered guidelines for people writing third-party profiles and extensions, and a lighter-weight version of this might be nice to have on record if there's any complexity to it. Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] What are the OAuth design principles?
Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document. You can find it here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements The discussion is around "Why can't Kerberos just be used for your use cases?" The UMA principles might be able to inform how the OAuth WG makes its case for why Kerberos doesn't suffice. (If we discover it does, hey, our work here is done. :-) Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] First draft of OAuth 2.0
Selected thoughts in response: On 21 Mar 2010, at 3:51 PM, David Recordon wrote: > Thanks! Comments inline and updated the repo > (http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a). > > On Sun, Mar 21, 2010 at 12:03 PM, Eve Maler wrote: >> David, great stuff -- thanks for putting this together! Here are a few >> comments and questions from a quick read on the plane down to Anaheim, in >> spec order (the weight/priority therefore varies widely). >> >> Abstract >> >> - "delegate": The use of this word seems like it's different from how it's >> been used in the past, e.g. in "user delegation". It's not a big deal, but >> possibly confusing. > > Rephrased a bit, but someone should just rewrite the abstract to begin with. I can stab at this by Friday, if someone else doesn't get there first... >> - It would be helpful to give really concrete examples/use cases of all of >> the profiles in the intro, so people can determine from this single place >> which profiles interest them. > > Each flow starts with one or two sentences trying to describe when > they should be used. I'm perfectly willing to admin that they might > not be complete. Happy to accept text from anyone! (Same goes for the > intro.) Another item I may get a chance to play with by the end of the week. >> - I'm thinking oauth_error_reason is where UMA could define an extension >> that gives an error like "claims_required". I need to sort this out with my >> gang, but provide it here as food for thought. Should we be defining our >> own parameter instead (and if so, should this spec say something about cases >> where this is done by others)? Alternatively, should this spec allow for >> extended error codes in some formal fashion? > > Error codes are coming up quite a bit. In general you should rely on > HTTP error responses, but there are cases where they're not specific > enough. I'd really appreciate a list of error reasons that > implementors would like to see in the protocol. A combined list will > help make it happen. Seems like we should start a thread about this. I'll raise the question of the claims_required code at the UMA meeting on Thursday, and feed back any input. > >> 2.5. Client Identifier and Secret Flow >> >> - "This flow is suitable when the client is also the resource owner": I >> think this was supposed to be the "two-legged"/"autonomous-client" solution, >> but this phrase throws that into doubt for me. What was the intent here? >> Note that UMA (like a lot of others) is interested in solving automated >> self-registration of an autonomous client at an authorization server. (In >> case it's of interest, we've been trying to sort out the legal implications >> of parties who are *not* the resource owner seeking authorized access; this >> is where our "claims_required" stuff comes in. Sometimes the client >> represents "itself", or rather a company or org acting on its own behalf; >> sometimes it represents a person different from the resource owner; etc. >> See our Lexicon at >> http://kantarainitiative.org/confluence/display/uma/Lexicon.) > > You're right. Can you help reword please? How about simply: "This flow is suitable when the client acts autonomously in seeking access and is thus not accessing protected resources within the context of a given end-user." > >> - "the protected resource MUST NOT allow the user of the corresponding >> access token without its secret": This is a case where "[protected resource] >> server" would work way better than "protected resource", as resources don't >> allow or disallow actions; they just exist. > > hmm, does read a bit better in most cases. Means changing the > definition as well. What do others thing? (I think it's all hanging together nicely now, but I'm biased. :-) Note that there are still some instances of "protected resource" that now want to be "server" -- I see one in the first sentence of 4.1.1, and this probably happens all over section 4. A final new comment: The spec says nothing at all about how a token gets validated, which may be fine, but given that several different means of token validation have been discussed (here and on the WRAP list of late), should something explicit be said that puts the validation method out of scope for this spec? Eve Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] First draft of OAuth 2.0
On 21 Mar 2010, at 1:43 PM, David Recordon wrote: > The goal of the, "the authorization server advertises (such as via > documentation) the URIs of the following three endpoints" wording was to > allow for a discovery process that is defined separately from this spec. Is > that unclear? Have other words to propose? So perhaps this wants to be a thin spec that can be combined with the OAuth core spec, if there's general interest in it. (In the UMA spec, we were already in the position of making up some XRD to describe a couple of WRAP endpoints, along with UMA endpoints and metadata. It would be nice to have a canonical version of the former, at the least.) > > Eve, thanks for the detailed feedback! Future email coming with commits or > comments for each one. Hopefully sometime before the actual meeting tomorrow, I'll respond with spec text ideas where you -- very reasonably :-) -- asked me to supply some. Eve > > --David > > On Mar 21, 2010, at 12:53 PM, John Panzer wrote: > >> +1 to ensuring that dynamic introduction is possible. I see a lot of >> discussions that end up saying that this or that can be spec'd in the >> server docs and the client hard coded to the docs; this is fine for >> some features but not for very general ones that everybody needs to >> use. Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] First draft of OAuth 2.0
ory – on my public GitHub account a > thttp://github.com/daveman692/OAuth-2.0. Eran will be doing an initial > editing pass before Monday and then spend more time with it next week. > > I've attached both a HTML and TXT copy to this email and plan to officially > submit it as an Internet Draft. > > The following are highlighted changes from draft-hardt-oauth-01: > 1. A Web Client flow designed for use within JavaScript. It also > supports the use cases of the rich app profile so that they're > not two separate flows. > 2. A new device flows which is based on the Netflix/Tivo flow (TV > shows you a code that you type in on your computer). > http://www.ietf.org/mail-archive/web/oauth/current/msg01346.html > 3. Remove captchas from the username/password flow. They haven't > been successfully implemented within this context and create > complexity especially when we use other signals to detect > compromised accounts. > http://www.ietf.org/mail-archive/web/oauth/current/msg01293.html > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > 5. Abstract the refresh token flow out of each profile into its own > section. Support the ability to request access token secrets > when refreshing. > 6. Support signatures for making API requests but not for getting > access tokens. If you want to use signatures, you'll get an > access token and then make a refresh call where you ask for a > token secret. This causes the auth server to mark the token as > no longer being valid as a bearer token via SSL. This > performance tradeoff seems realistic given many use cases focus > on high-volume API transactions and thus the one additional > request at the onset should be noise. The signature mechanism is > currently from OAuth 1.0. > > Obviously I couldn't have made so much progress so quickly if it weren't for > WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those > we all have been discussing here. I hope that I haven't missed anyone who > contributed to prior work and am happy to add other authors if I have (and > they wish to be added)! > > Thanks, > --David > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dinner Sunday?
I'm game. Was planning to go to the welcome reception 5-7pm; should we gather there and head out? We can use the LDP (Lightweight Dinner Protocol) -- whoever is there by 7 can come along. ;) Eve On 20 Mar 2010, at 1:28 PM, David Recordon wrote: > Not sure how many people will be in Anaheim Sunday evening, but should > we try to put a dinner together? 7pm-ish? Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Signatures, Why?
Hi Brian, On 16 Mar 2010, at 10:51 AM, Brian Eaton wrote: > We didn't talk about the signed identity claims use case. Some > background on that is in this thread: > > http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html > > Paul - does OpenSocial still need signed identity claims? > > Eve - does UMA still need signed identity claims, or are you handling > that outside of the OAuth spec? UMA's core protocol is agnostic as to the format of the claims, though negotiating a desired claim format does have a few core-protocol implications. We anticipate that a couple of different formats are likely (strong interest has been expressed in SAML and JSON so far). We do have use cases for third-party-asserted claims as well as self-asserted claims, and we anticipate that the former would be most easily solved (maybe "easily" should be in scare quotes) with signatures. The use cases requiring this do tend to be for higher-security, higher-sensitivity applications (health, financial/insurance, etc.). Note that by "claims", I'm referring here to the access authorization claims that an authorization manager would ask a requester to produce in order to prove suitability for getting access. (The authorizing user might be delegating access to some protected web resource that contains identity claims about themselves; this is well outside the UMA core protocol.) Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Signatures, Why?
Agreed that token signing is separate from message signing as a proposition. I just happened to stick all of our "signing" conversations into one bucket of notes... Sorry that was confusing. Eve On 12 Mar 2010, at 11:06 AM, Brian Eaton wrote: > On Fri, Mar 12, 2010 at 10:22 AM, Eve Maler wrote: >> It was observed that the argument in the OAuth community about token size >> seems to be related to token signing, thusly: those who are willing to >> require the Authorization Server to be stateless need large meaningful >> tokens and want them signed; those who can use a stateful Authorization >> Server can use small opaque tokens that don't need signing. > > This seems orthogonal. The confusion in this working group has not, > for the most part, been about whether access tokens should be signed. > > The debate has been more about whether clients need to use signatures > when requesting access tokens, or when using access tokens. On one > side there are people who would prefer bearer tokens, and on the other > side there are folks who want crypto in various bits of the protocol > to meet different use cases. > > Cheers, > Brian Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Token validation and other host/authz communication
In the recent thread here: http://www.ietf.org/mail-archive/web/oauth/current/msg01234.html Subject: "Recent UMA work that may inform this group's deliberations" ...Dick and I had a bit of discussion around UMA's proposal for a back-channel method of token validation that a Protected Resource could use at an Authorization Server. (In UMA terms, it would be a Host->Authorization Manager interaction, and indeed if this channel is inappropriate for core OAuth 2.0, UMA might define it as a separate subordinate protocol.) At the UMA F2F held Wednesday, we discussed this proposition in some detail, and continued to find the back channel interesting in our loosely coupled environment. Below I have reproduced the portion of meeting notes (from http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-10 ) where we discussed this. I hope it's useful/interesting. Eve Back channel for token validation: Our "token validation URL" proposal is just a strawman. There are quite a few motivations for wanting this back channel, though: It allows for building a very lightweight host that can do token validation at request-time. The AM is the best entity to judge the token's suitability. Once this channel is enabled, the host can use it send audit log data to the AM for more interesting analytics. Or the AM could (at leisure after step 1 is done) dynamically provision the host with the ability to do local token validation (which ends up looking like a hybrid remote/local means of validation). Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Signatures, Why?
Here is some late input to this thread. The UMA group had a F2F meeting on Wednesday, for which draft minutes are written up here: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-10 I had taken an action from the last OAuth telecon to collect UMA use cases that related to the "signature question(s)". I have reproduced the various meeting notes on this point below. In essence, the UMA group continued to agree that message signing should remain an option, even with SSL in the picture, for authentication and auditing reasons. Note that Tom Holodnik of Intuit took away an action item to formally write up and submit the small-business UMA scenarios he's been referring to in our ongoing work (hinted at below), so we expect those soon. The health-data scenario at http://kantarainitiative.org/confluence/display/uma/hdata_scenario is also likely to have higher security and service-authentication requirements that could end up demanding message signing. Other submitted scenarios, so far, seem to have security requirements that are less stringent. (I'll send another message in a moment on our discussion of the token validation question.) Eve Signing: Using today's WRAP, an UMA authorizing user can't be absolutely sure (based on a signed message) who accessed his protected resource, other than the client's IP address. It's only indirectly known by the AM, and that's only if a user policy made the AM demand some claim from the requester, and even so the authentication is at a "higher" level of the stack. So wherever there's a use case that requires that the access token be bound to the requester who wields it, we need signatures. This nets out to the requesting party (person or company seeking access) having an incentive to say "It's really me accessing this", such that it mitigates the risk that the requester (client) will hand off both the access token and the signing secret to a third party. Online banking might rise to this level. But if you install TurboTax on your PC, is it likelier that you the requesting user would sign something that gets bound to your TurboTax instance, or sign something that gets handed to your TurboTax instance as a bearer token that they use on your behalf without the binding? TomH feels that, yes, it's quite possible for this to be a value-add provided by something like TurboTax as a "trusted computing" offering. It was observed that the argument in the OAuth community about token size seems to be related to token signing, thusly: those who are willing to require the Authorization Server to be stateless need large meaningful tokens and want them signed; those who can use a stateful Authorization Server can use small opaque tokens that don't need signing. On 11 Mar 2010, at 9:56 PM, Torsten Lodderstedt wrote: > I volunteer to write it up. >> >> >> On 3/4/10 1:00 PM, Blaine Cook wrote: >> >>> One of the things that's been a primary focus of both today's WG call >>> and last week's call is what are the specific use cases for >>> signatures? >>> >>> - Why are signatures needed? >>> - What do signatures need to protect? >>> >>> Let's try to outline the use cases! Please reply here, so that we have >>> a good idea of what they are as we move towards the Anaheim WG. >>> >> This was a valuable thread. Perhaps someone could write up a summary of >> the points raised, either on the list or at the wiki? >> >> Peter Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations
Thanks for your further feedback. Just a couple of comments back (eliding other portions of the thread): On 8 Mar 2010, at 2:21 PM, Dick Hardt wrote: > On 2010-03-05, at 6:57 AM, Eve Maler wrote: >>>> >>>> 2c. Currently, WRAP doesn't say anything about how to fill the scope >>>> parameter value. In this context, an obvious optimization is the "all the >>>> photos that happen to be in this folder" authorization scenario. So we >>>> went ahead and proposed a simple JSON-based format for describing both >>>> simple access scope and basic wildcarded access scope. >>> >>> Different scenarios will require different scope values. We thought it >>> useful to define the parameter so that it would be easier library >>> providers and specs like UMA to define the value without also having to >>> define the parameter. >> >> I'd like to learn more about the other use cases. If common cases exist and >> can be sedimented in for more universal support, that would be cool. (If >> not, okay.) But along the lines of my earlier comment on extension points, >> I'm not sure standardizing the field is valuable without standardizing any >> values at all -- it may just confuse people about whether they're supposed >> to stuff a bunch of different things into the one parameter if they seem >> vaguely "scope"-related, or invent their own, or whatever. And then you >> have to worry about how to stuff incompatible scope values into the same >> parameter side by side for hybrid use cases that use multiple extensions. >> Etc. > > The feedback we received from library writers was standardizing the syntax > was useful. There was little agreement on what the value of wrap_scope would > be across implementors, but all agreed a standard parameter for scope was > useful. We could add to the spec to clarify how the scope parameter should be > used. It could make sense for UMA to standardize what the scope values are. It's a good idea to give guidance on how the scope parameter should be used. That way, it will help avoid "abuse" of the parameter for other purposes, and clashes if different deployments are using it in different ways. (I suspect that the tradeoff here is making it (superficially?) appealing for implementers vs. making it more interoperable for deployers.) > >>>> 3. The means by which a host interprets an incoming access token is not >>>> currently specified in WRAP. Unfortunately, UMA needs to know. :-) There >>>> seem to be two options: validating it locally or offloading validation. >>>> To avoid putting a signature validation burden on the host, we have >>>> proposed a strawman where the host can simply ask the AM to do the >>>> validation for it. (A personal observation: The local/offload choice all >>>> depends on various scale and loose coupling factors, but this is appealing >>>> for lots of reasons. It not only views the Authorization Server as an STS >>>> performing a typical token validation function, but pretty closely matches >>>> the classic access management paradigm where the policy enforcement point >>>> asks the centralized policy decision point what to do. And other useful >>>> info could also ride over this back channel, either in extensions or -- as >>>> the need arises -- in core OAuth.) >>> >>> When developing WRAP, we envisioned that the PR would verify and interpret >>> locally. >> >> It's probably worth mentioning that at least two UMA scenarios (health data, >> and distributed social networking services with "data portability") envision >> applications that frequently serve as both hosts/PRs and requesters/clients, >> so if processing burdens are removed from the client but placed on the PR, >> it may not help us all that much. This is an area where I hope others can >> chime in with use cases and constraints to figure out which "scaling" >> options suits them best. (And if WRAP/OAuth remains silent on the issue, it >> seems UMA could still define this loop as an extension.) > > I'm confused by your comments. The Client does not do any processing of the > Access Token. Would you clarify who you are trying to offload Access Token > validation from and to? Right, the Client doesn't do this processing. However, if the point of making tokens opaque to "the Client" is to save them trouble, I wanted to point out that some of our use cases have the same overall application deploying a
Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations
More below... On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote: > Thanks Eve, comments inserted ... > > On 2010-03-04, at 12:51 PM, Eve Maler wrote: > >> As requested on today's call, here's a description of the places where UMA >> seems to need "more" than what the WRAP paradigm offers (both profiling and >> extending), based on the proposal at: >> >> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol >> >> Cautions in reading this note: >> >> - The mix of likely needed profiles and extensions for our use of the OAuth >> 1.0 paradigm (the existing spec on the UMA site) is quite different from the >> list presented here, and in addition, that spec wasn't written with a goal >> to highlight such items the way this proposal was. >> >> - The proposal is currently fairly high-level, and other profiling/extension >> needs may come to light if we proceed down this path -- or some of the needs >> may disappear. The proposal nonetheless tries to document profile and >> extension points as precisely as possible. >> >> - UMA's terminology is similar but not identical to WRAP's. The proposal >> tries to be as clear as possible about the distinctions, but caveat lector. >> >> - For all of the profile/extension items listed, they may be of interest >> only to UMAnitarians, or they might have wider application as optional or >> required portions of a core OAuth 2.0 spec. We're not trying to prejudice >> this outcome, just provide useful information for making the decision in the >> wider community. >> >> So, with all that said... Here is the conception of UMA's use of the WRAP >> paradigm as conceived in the proposal. >> >> 1. Currently, WRAP says nothing about how a Protected Resource and an >> Authorization Server "meet" and figure out how to work together. > > This was explicitly out of scope for WRAP. There are scale and privacy > advantages to the PR and AR not meeting. The PR needs to trust the AR the > issued the Access Token (and of course be able to verify the Access Token was > issued by the AR), but the AR does NOT need to be aware of the PR. In this > way, WRAP (Unfinished sentence?) As noted above, it's fine for this to be out of scope for WRAP itself, but it's in UMA's scope. > >> UMA has reason to make the user's choice of authorization management (AM) >> services and hosts of their resources be dynamic and flexible -- that's why >> it's called "user-managed access" -- so the proposal suggests a special way >> to use (an embedded instance of one of the user delegation profiles of) WRAP >> to introduce them, as a "step 1". (The token thus acquired by the host in >> this step plays a role in "step 3".) > > Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is > there some functionality missing? I don't understand the comment/question. Are you suggesting the WRAP pattern (same as the three-legged OAuth pattern, which our current spec uses) can't be applied to new use cases? It's pretty much a vanilla application of the pattern. If it's not interesting as a generic solution and the problem space is only UMA's, that's certainly okay with us. > >> >> 2a. Another of UMA's goals is to allow authorizing users (roughly, Resource >> Owners) to make demands of other parties before granting them access rather >> than just permissioning the connection "silently". The mechanism for making >> these demands is to require the requesting side to provide claims (yes, in >> the identity claims sense) and even to make this process have legal >> enforceability consequences where possible. Thus, the proposal suggests an >> extended getting-a-token phase in a "step 2" that adds a new third option to >> the two usual WRAP options (successful access token response and >> unsuccessful access token response): a claims-required response. > > I can see it being useful in a standard return parameter that can contain an > value undefined by WRAP (similar to the scope parameter), that is used by the > AS to communicate to the Client what else the Client needs to be granted an > Access Token. Is this what you are asking for? I'm not sure if we're technically "asking for" anything, just floating the use case and pointing out that if we were to layer on WRAP as it's written today, we'd have to extend the possible responses to token req
Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations
Quick feedback... On 4 Mar 2010, at 5:42 PM, Dick Hardt wrote: > Hi Eve > > Looking at the WRAP oriented comments in the spec, here are some comments / > questions: > > Note > WRAP doesn't seem to say HTTPS is required for the user authorization URL; is > this a bug in the WRAP spec? If not, is it a good idea for us to profile it > in this way? Finally, is this the right place to say HTTPS is required for > all these URLs? > > Dick: an HTTPS requirement is prohibitive at times. See > http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/821e73bcbd8033dd?hl=en# > for a recent discussion on this. > Okay. > Note > Need lots of examples for all of this. Also, note that WRAP forces clients to > use POST on access token URLs and refresh token URLs; can we use GET in the > way described here? > > Dick: why do you want GET? There are security issues with using GET to the AS. We can probably do away with the GET we have, I'm guessing. We'll discuss. > > Note > Obviously this is just the highest-level sketch of what needs to happen! This > needs to be fleshed out. (E.g., the wrap_scope format could be reused here, > without any wildcards.) > Also, are we concerned that a malicious host could lie about the attempted > resource and method? The only consequence seems to be "false negatives" in > managing authorized access, in which case the user would get unhappy pretty > quickly. > > Dick: it was envisioned that the scope of a function of scope would be > embedded in the Access Token. Or perhaps I don't understand the issue. I can see three places a description of scope may need to appear. 1. Initial request for token sent by client/requester to AM/AS, so that the right kind of token can be created - this presumably has to be in-band in the protocol. (This is why there's a wrap_scope parameter on the request and nowhere else, right?) This is what we defined it in the proposed UMA step 2. 2. In the token itself. Indeed this is out of band of the protocol itself. 3. If the protected resource/host outsources token validation (such that the token is opaque to the host as well as the client/requester), then the host would need to supply a description of the attempted access made by the client/requester along with sending the token for validation. The note you're responding to just above is this third case. Eve > > > On 2010-03-04, at 11:01 AM, Eve Maler wrote: > >> Folks may be interested to see the following experiment being performed in >> the UMA group: >> >> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol >> >> This is a proposal for a spec that uses a WRAP-friendly approach to solving >> our use cases. Please note the final comments in today's UMA telecon >> minutes for cautions about additional requirements we have: >> >> http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04 >> >> Eve >> >> Eve Maler >> e...@xmlgrrl.com >> http://www.xmlgrrl.com/blog >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations
he overall risks in using the WRAP paradigm for controlling access to various kinds of sensitive information in various ways. It may not be acceptable in some UMA use cases, e.g., to use replayable tokens. As I promised on the call, I'll work with the UMA group to research this issue as precisely as possible in preparation for Anaheim, ideally including specific guidance from those who have submitted the most sensitive UMA scenarios or have the biggest concerns. Eve On 4 Mar 2010, at 11:01 AM, Eve Maler wrote: > Folks may be interested to see the following experiment being performed in > the UMA group: > > http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol > > This is a proposal for a spec that uses a WRAP-friendly approach to solving > our use cases. Please note the final comments in today's UMA telecon minutes > for cautions about additional requirements we have: > > http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04 > > Eve > > Eve Maler > e...@xmlgrrl.com > http://www.xmlgrrl.com/blog > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Recent UMA work that may inform this group's deliberations
Folks may be interested to see the following experiment being performed in the UMA group: http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol This is a proposal for a spec that uses a WRAP-friendly approach to solving our use cases. Please note the final comments in today's UMA telecon minutes for cautions about additional requirements we have: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04 Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting)
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 Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] terminology
Related to this, in UMA we chose "Host" for the online service where a protected resource can be accessed, because each resource found there might potentially be subject to a different user-managed authorization policy (that is, protection) regime. We've found this word to be quite copacetic, as it's short and intuitive, has a unique single-letter abbreviation, and doesn't imply that the service is the same thing as a particular resource available at the service. At first, we tried to stick with "SP" for this entity -- this was before the server/client terminology emerged in the OAuth 1.0 cleanup effort -- but found it to be too confusing because the Host has an OAuth-mediated relationship with the UMA Authorization Manager (note, not the same thing as a WRAP Authorization Server!) that is consumer->SP / client->server. I wonder if "Host" can work in the context of the WRAP patterns too, since all the same things are true about this word in both contexts... BTW, here's a direct link to the UMA terminology section: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol#UMA1.0CoreProtocol-Terminology Eve On 2 Feb 2010, at 2:41 PM, Peter Saint-Andre wrote: > On 2/2/10 3:12 PM, Dick Hardt wrote: >> >> On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote: >>> On 1/28/10 11:35 PM, David Recordon wrote: >>>> I have a pretty strong preference of sticking with OAuth 1.0 >>>> terminology as much as possible. >>> >>> Agreed. >> >> The term "server" in OAuth 1.0 does not differentiate between the >> Authorization Server and Protected Resource as are differentiated in >> OAuth WRAP. >> >> The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes >> to provide additional clarity. > > I meant to say "agreed, where possible and reasonable". The point of > this exercise is to make sure that we differentiate where that makes > sense. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FYI, UMA webinar followup
Hi-- We had a bit of a glitch in the half-hour before the webinar, and sent out fresh notification emails. It sounds like you didn't get yours, for which I'm very sorry! We had about 20 people on. There will be a recording (audio/video) available soon -- I'll alert this list at that time -- and the slides and wireframes are all linked from here: http://kantarainitiative.org/confluence/display/uma/UMA+Explained Specifically, we presented these materials in the order listed: http://kantarainitiative.org/confluence/download/attachments/37751312/uma-webinar-2010-01-29.pdf http://kantarainitiative.org/confluence/download/attachments/37751312/UMA_CV_wireframeV7.pdf http://kantarainitiative.org/confluence/download/attachments/37751312/UMA-protocol-flow-deep-dive.pdf Eve On 29 Jan 2010, at 11:24 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I registered for the seminar, got the bridge info, dialed in and nobody > was there. > Are there slides available? > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >> On Behalf Of ext Eve Maler >> Sent: 25 January, 2010 14:03 >> To: OAuth WG >> Subject: [OAUTH-WG] FYI, UMA webinar followup >> >> I think I mentioned on last week's call that those of us >> working on UMA are doing a status update in a webinar on >> Thursday of this week. You're invited to sign up (there's a >> small handful of slots left). Info and registration link are here: >> >> http://kantarainitiative.org/confluence/display/uma/Meetings+an >> d+Minutes >> >> Eve >> Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] FYI, UMA webinar followup
I think I mentioned on last week's call that those of us working on UMA are
doing a status update in a webinar on Thursday of this week. You're invited to
sign up (there's a small handful of slots left). Info and registration link
are here:
http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
