Re: [OAUTH-WG] Agenda for Atlanta Meeting
Hi Justin, Hi Torsten, We will take care of appropriate time management and agenda topics that have not seen enough presentation on the list will be postponed. In fact, I am concerned about the progress with the use cases document and the dynamic client registration work. I have notified the authors of my concerns privately already. Ciao Hannes On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: +1 Richer, Justin P. jric...@mitre.org schrieb: Good for me, AS LONG AS we make absolutely SURE that we leave plenty of time for #8 on the agenda, to the point of cutting off and tabling other discussions ahead of time. There are a lot of ancillary documents in various states of use/neglect that shouldn't be left aside by the WG, and this is a good venue for all of that. -- Justin On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: +1 Zachary -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Saturday, October 06, 2012 2:54 PM To: Torsten Lodderstedt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting +1 Phil On 2012-10-06, at 10:07, Torsten Lodderstedt tors...@lodderstedt.net wrote: fine for me Am 05.10.2012 10:03, schrieb Hannes Tschofenig: Hi all, here is an agenda proposal for the Atlanta IETF meeting: (The indicated names are proposals.) -- Agenda: 1. Status Update, Agenda Bashing (Chairs) 2. Token Revocation (Thorsten) 3. Assertions (Brian + Mike) 4. OAuth Use Cases (Zachary) 5. JWT (Mike) 6. Security (Phil) 7. Dynamic Client Registration (Thomas) 8. Roadmap -- In the last item we would like to discuss the bigger picture of how to get OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (a) what other specifications do we need to work on, and (b) how do we improve interoperability. Let us know whether you think that this fits your needs. Ciao Hannes Derek PS: I am hoping to see daft updates of the WG items soon. 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-WG] Out-of-band code delivery and alternate redirect_uri schemes
1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special urn:ietf:wg:oauth:2.0:oob to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative redirect_uri schemes I'm also considering the use of alternative schemes on the redirect_uri. For instance, a client app could use the mailto:; scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth Use Cases Author(s) : George Fletcher Torsten Lodderstedt Zachary Zeltsan Filename: draft-ietf-oauth-use-cases-02.txt Pages : 24 Date: 2012-10-10 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-use-cases-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt
On behalf of the co-authors I have posted the draft. The main changes in the -02 version are the following: · Removal of the use case on re-delegation. (The case is too far from the present OAuth 2.0) · Clarification of the use case Device · Addition of a note for each use case that indicates whether the use case supported by OAuth 2.0 · Update of the references · Inclusion of the references to the WG security documents in the Security Consideration section Your comments are welcomed. Particularly, the authors are looking for advice with the use of the example URLs. Following the guidance of RFC 2606, we have used “example” as the top level domain name (e.g., example.com). This may mislead readers into thinking that all URLs belong to the same organization. A general note, stating that all sites ending with “example.com” do not necessarily belong to the same organization, is not sufficient (according to some readers). How to avoid the confusion? Zachary -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Wednesday, October 10, 2012 11:46 AM To: Zeltsan, Zachary (Zachary) Cc: tors...@lodderstedt.net; gffle...@aol.com Subject: New Version Notification for draft-ietf-oauth-use-cases-02.txt A new version of I-D, draft-ietf-oauth-use-cases-02.txt has been successfully submitted by Zachary Zeltsan and posted to the IETF repository. Filename:draft-ietf-oauth-use-cases Revision: 02 Title: OAuth Use Cases Creation date: 2012-10-10 WG ID: oauth Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-ietf-oauth-use-cases-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases Htmlized:http://tools.ietf.org/html/draft-ietf-oauth-use-cases-02 Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-use-cases-02 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt
You can use example.com, example.org, and example.net, if you think that would help. We do that in the OpenID Connect specifications. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Zeltsan, Zachary (Zachary) Sent: Wednesday, October 10, 2012 9:30 AM To: 'oauth@ietf.org WG' Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt On behalf of the co-authors I have posted the draft. The main changes in the -02 version are the following: ·Removal of the use case on re-delegation. (The case is too far from the present OAuth 2.0) ·Clarification of the use case Device ·Addition of a note for each use case that indicates whether the use case supported by OAuth 2.0 ·Update of the references ·Inclusion of the references to the WG security documents in the Security Consideration section Your comments are welcomed. Particularly, the authors are looking for advice with the use of the example URLs. Following the guidance of RFC 2606, we have used “example” as the top level domain name (e.g., example.com). This may mislead readers into thinking that all URLs belong to the same organization. A general note, stating that all sites ending with “example.com” do not necessarily belong to the same organization, is not sufficient (according to some readers). How to avoid the confusion? Zachary -Original Message- From: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]mailto:[mailto:internet-dra...@ietf.org] Sent: Wednesday, October 10, 2012 11:46 AM To: Zeltsan, Zachary (Zachary) Cc: tors...@lodderstedt.netmailto:tors...@lodderstedt.net; gffle...@aol.commailto:gffle...@aol.com Subject: New Version Notification for draft-ietf-oauth-use-cases-02.txt A new version of I-D, draft-ietf-oauth-use-cases-02.txt has been successfully submitted by Zachary Zeltsan and posted to the IETF repository. Filename:draft-ietf-oauth-use-cases Revision: 02 Title: OAuth Use Cases Creation date: 2012-10-10 WG ID: oauth Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-ietf-oauth-use-cases-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases Htmlized:http://tools.ietf.org/html/draft-ietf-oauth-use-cases-02 Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-use-cases-02 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt
Particularly, the authors are looking for advice with the use of the example URLs. Following the guidance of RFC 2606, we have used “example” as the top level domain name (e.g., example.com). This may mislead readers into thinking that all URLs belong to the same organization. A general note, stating that all sites ending with “example.com” do not necessarily belong to the same organization, is not sufficient (according to some readers). How to avoid the confusion? You're not using it as the top level domain name. You're using it as the second level domain name. See below. As Mike says, you can use .net and .org as well as .com. You can also use example truly as the top level domain (TLD). You can use company1.example and company2.example and big-university.example, and so on. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt
Thank you, Barry and Mike: I will make changes for the next version. Zachary -Original Message- From: barryleiba.mailing.li...@gmail.com [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba Sent: Wednesday, October 10, 2012 12:46 PM To: Zeltsan, Zachary (Zachary) Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt Particularly, the authors are looking for advice with the use of the example URLs. Following the guidance of RFC 2606, we have used example as the top level domain name (e.g., example.com). This may mislead readers into thinking that all URLs belong to the same organization. A general note, stating that all sites ending with example.com do not necessarily belong to the same organization, is not sufficient (according to some readers). How to avoid the confusion? You're not using it as the top level domain name. You're using it as the second level domain name. See below. As Mike says, you can use .net and .org as well as .com. You can also use example truly as the top level domain (TLD). You can use company1.example and company2.example and big-university.example, and so on. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] UMA Webinar on Oct 17th
FYI folks, There will be a free webinar on UMA in Higher Education on October 17th 2012. Info below. /thomas/ Webinar on UMA and Higher Education on Wednesday, October 17 Our next webinar is scheduled for Oct 17 at 8am PT! The topic is UMA and Higher Education. We'll show an extensive demo of how students can manage access by a variety of prospective employers to distributed, trusted information about their educational achievements. Join us (details on our calendar), and follow @UMAWG and hashtag #UMAedu for news. --- Meeting information --- Topic: Webinar: UMA and Higher Education #UMAedu Date: Wednesday, October 17, 2012 Time: 10:30 am, Eastern Daylight Time (New York, GMT-04:00) Meeting Number: 252 418 084 Meeting Password: (This meeting does not require a password.) --- To start or join the online meeting --- Go to https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=191340043UID=498898617RT=MiMxMQ%3D%3D --- Teleconference information --- Provide your phone number when you join the meeting to receive a call back. Alternatively, you can call: Call-in toll-free number: 1-866-2030920 (US) Call-in number: 1-206-4450056 (US) Show global numbers: https://www.tcconline.com/offSite/OffSiteController.jpf?cc=5423695925 Leader PIN: 99171 Conference Code: 542 369 5925 --- For assistance --- 1. Go to https://ieeemeetings.webex.com/ieeemeetings/mc 2. On the left navigation bar, click Support. To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=191340043UID=498898617ICS=MIULD=1RD=2ST=1SHA2=KyYnWEkDkzKfKYJ3FDZUoQ8Cow2pBr8UPws0/py9/R0= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ieeemeetings.webex.com/ieeemeetings/systemdiagnosis.php http://www.webex.com CCM:+12064450056x99171# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. more details copy to my calendar ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes
Hi Pedro, Am 10.10.2012 16:25, schrieb Pedro Felix: 1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special urn:ietf:wg:oauth:2.0:oob to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative redirect_uri schemes I'm also considering the use of alternative schemes on the redirect_uri. For instance, a client app could use the mailto:; scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? What address should the authorization server send an e-mail to and how would the app acquire this code? regards, Torsten. Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 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 prab...@wso2.com 2012-10-09 20:35 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler e...@xmlgrrl.com, 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, zhou.suj...@zte.com.cn 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
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 e...@xmlgrrl.com 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 prab...@wso2.com* 2012-10-09 20:35 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler e...@xmlgrrl.com, 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, *zhou.suj...@zte.com.cn*zhou.suj...@zte.com.cn 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 -- 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
Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes
Hi Pedro, Am 10.10.2012 16:25, schrieb Pedro Felix: 1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special urn:ietf:wg:oauth:2.0:oob to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative redirect_uri schemes I'm also considering the use of alternative schemes on the redirect_uri. For instance, a client app could use the mailto:; scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? What address should the authorization server send an e-mail to and how would the app acquire this code? regards, Torsten. The email address would be in the redirect_uri; the code would be inserted into the client app explicitly by the user, after receiving it. Thanks Pedro Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 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 prab...@wso2.com 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 e...@xmlgrrl.com 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 prab...@wso2.com 2012-10-09 20:35 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler e...@xmlgrrl.com, 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
Re: [OAUTH-WG] Resource owner initiated OAuth delegation
Hi, Eve, The requester you described corresponds to Client in OAuth, so it is still client initiated delegation, not what Prabath wants. Eve Maler e...@xmlgrrl.com 2012-10-11 06:54 收件人 Prabath Siriwardena prab...@wso2.com 抄送 zhou.suj...@zte.com.cn, oauth@ietf.org WG oauth@ietf.org 主题 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 prab...@wso2.com 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 e...@xmlgrrl.com 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,
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 e...@xmlgrrl.com 2012-10-11 06:54 收件人 Prabath Siriwardena prab...@wso2.com 抄送 zhou.suj...@zte.com.cn, oauth@ietf.org WG oauth@ietf.org 主题 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 prab...@wso2.com 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 e...@xmlgrrl.com wrote: There are a number of implicit actions happening
Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes
So you assume to use resource owner's address? Regards, Torsten. Pedro Felix pmhsfe...@gmail.com schrieb: Hi Pedro, Am 10.10.2012 16:25, schrieb Pedro Felix: 1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special urn:ietf:wg:oauth:2.0:oob to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative redirect_uri schemes I'm also considering the use of alternative schemes on the redirect_uri. For instance, a client app could use the mailto:; scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? What address should the authorization server send an e-mail to and how would the app acquire this code? regards, Torsten. The email address would be in the redirect_uri; the code would be inserted into the client app explicitly by the user, after receiving it. Thanks Pedro Thanks Pedro ___ 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
