Re: [OAUTH-WG] native app support (was: Next draft)
Two points: 1/ I agree that it can be onerous for clients to host web pages. It's not a matter of expense but of complexity. BUT 2/ As we discussed previously in our in-person meeting, this should be handled by a different endpoint, and not be the responsibility for the provider. If Google wishes to support this for their desktop apps, then it should provide an endpoint that handles the OAuth response and puts it in the title. I can say that Facebook has no interest in supporting this hack on the server side, but clients that want it can use their own html file that does it for them. For example, for Javascript web apps it is a pain to host a cross-domain receiver file. So we host one on behalf of developers (called xd_proxy.php). But it is not part of our server-side logic. If you want to write a spec for that, then great, but the title hack does not belong in the main spec. On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In that case, I suggest an extension. But I just don't think this needs it. Why involve the server at all in this? The client should just host a web page somewhere with the format it wants or the language for the user. With $10 hosting, every client can host a web page somewhere. Hard to tell, you could be right. Keep in mind that this page has to be reliable and secure, $10 will probably not give you that. An authz server can easily provide all this at almost no cost. Marius EHL -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 4:17 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 3:35 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in the spec because it doesn't help interop. If the server supports such a scheme, it should document it. It also falls under previously established redirection URI which happens to point at the server. OK, that makes sense. What about: Also, this page should put the verification code and the client state (code and state) in the page title in a standard way such that the native app can extract them from the window title. WRAP defined how the title should be formed. Extension? I don't think this needs a spec. Just something provided by the server. Does the client need any special handling? It can always just use a static web page to do this, no? A spec would help so all servers provide code and state in a consistent format. Client libraries can then provide methods to parse this. Also, client apps connecting to multiple servers can expect some consistency. Marius EHL Marius EHL -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 1:02 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu mscurte...@google.com wrote: In order to properly support native applications I suggest the following changes: [...] 2. optional redirect_uri (default result page) Some native apps do not have a redirect_uri, as a result two things are needed: 2.1 Either make redirect_uri optional or define a standard value that signals that the client does not have such a page. 2.2 The authz server must supply a default result page, if there is no redirect_uri. Also, this page should put the verification code and the client state (code and state) in the page title in a standard way such that the native app can extract them from the window title. WRAP defined how the title should be formed. Should this also go to an extension? It is not introducing any new parameters, not sure if it belongs there. OAuth 1 at least defined the oob special value. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] native app support (was: Next draft)
One more question - is the title technique used in production? I think you'd mentioned that it was ... if so, can you point me to the docs where it's currently used? On Jun 22, 2010, at 11:00 PM, Luke Shepard wrote: Two points: 1/ I agree that it can be onerous for clients to host web pages. It's not a matter of expense but of complexity. BUT 2/ As we discussed previously in our in-person meeting, this should be handled by a different endpoint, and not be the responsibility for the provider. If Google wishes to support this for their desktop apps, then it should provide an endpoint that handles the OAuth response and puts it in the title. I can say that Facebook has no interest in supporting this hack on the server side, but clients that want it can use their own html file that does it for them. For example, for Javascript web apps it is a pain to host a cross-domain receiver file. So we host one on behalf of developers (called xd_proxy.php). But it is not part of our server-side logic. If you want to write a spec for that, then great, but the title hack does not belong in the main spec. On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In that case, I suggest an extension. But I just don't think this needs it. Why involve the server at all in this? The client should just host a web page somewhere with the format it wants or the language for the user. With $10 hosting, every client can host a web page somewhere. Hard to tell, you could be right. Keep in mind that this page has to be reliable and secure, $10 will probably not give you that. An authz server can easily provide all this at almost no cost. Marius EHL -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 4:17 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 3:35 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in the spec because it doesn't help interop. If the server supports such a scheme, it should document it. It also falls under previously established redirection URI which happens to point at the server. OK, that makes sense. What about: Also, this page should put the verification code and the client state (code and state) in the page title in a standard way such that the native app can extract them from the window title. WRAP defined how the title should be formed. Extension? I don't think this needs a spec. Just something provided by the server. Does the client need any special handling? It can always just use a static web page to do this, no? A spec would help so all servers provide code and state in a consistent format. Client libraries can then provide methods to parse this. Also, client apps connecting to multiple servers can expect some consistency. Marius EHL Marius EHL -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, June 22, 2010 1:02 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: native app support (was: Next draft) On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu mscurte...@google.com wrote: In order to properly support native applications I suggest the following changes: [...] 2. optional redirect_uri (default result page) Some native apps do not have a redirect_uri, as a result two things are needed: 2.1 Either make redirect_uri optional or define a standard value that signals that the client does not have such a page. 2.2 The authz server must supply a default result page, if there is no redirect_uri. Also, this page should put the verification code and the client state (code and state) in the page title in a standard way such that the native app can extract them from the window title. WRAP defined how the title should be formed. Should this also go to an extension? It is not introducing any new parameters, not sure if it belongs there. OAuth 1 at least defined the oob special value. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Scope :: Was: Extensibility for OAuth?
On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: scope OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. Do folks think it would be useful to have standardized values? Not at this time. The semantics of scope are all over the place. If standardized, people will feel they need to pick one that is close to what they want, but is not exactly what they mean. I think it is better for the AS to define what they mean by a scope and give it a name that makes sense in that context. If the answer is yes, then it would be useful to differentiate the standardized values from those values that are purely defined locally by the authorization server. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth discovery draft?
I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article. [2] I define 'full delegation' as User X of Service Y grants permission Z to User A of Service B. Currently OAuth requires X == A. In the future I hope to see extensions to OAuth that enable what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X==A restriction. It simplifies a whole host of issues and satisfies a really important use case. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, June 21, 2010 9:50 PM To: Manger, James H; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth discovery draft? Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next. EHL -Original Message- From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Monday, June 21, 2010 8:03 PM To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: OAuth discovery draft? Eran, There have been a few mentions recently of an OAuth discovery draft. Is there any such draft yet, or is this just a part that we know needs to be done? The email on OAuth meeting notes on -05 (with updates) said: 6.1.1. - describing the WWW-Authenticate response header - Discovery needed for various elements Yes. That's for the discovery draft. A wiki page on Future OpenID Technical Requirements http://wiki.openid.net/Future-OpenID-Technical-Requirements says: 6) IdP Discovery * Much of this will be covered by OAuth2 Discovery, however OIC may need to define OpenID specific features. … 17) Simpler discovery * See Eran's OAuth Discovery proposal There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: expired, marked as obsolete by its author, discouraged from implementing, no update is expected, replaced by the OAuth 2.0 effort. I know I should write a discovery draft myself. -- James Manger ___ 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] OAuth discovery draft?
I think the core work is pretty stable now, unlike the discovery bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perhaps consider merging them later on when they reach an equal level of stability. But overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, Yaron Goland yar...@microsoft.com wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article. [2] I define 'full delegation' as User X of Service Y grants permission Z to User A of Service B. Currently OAuth requires X == A. In the future I hope to see extensions to OAuth that enable what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X==A restriction. It simplifies a whole host of issues and satisfies a really important use case. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, June 21, 2010 9:50 PM To: Manger, James H; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth discovery draft? Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next. EHL -Original Message- From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Monday, June 21, 2010 8:03 PM To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: OAuth discovery draft? Eran, There have been a few mentions recently of an OAuth discovery draft. Is there any such draft yet, or is this just a part that we know needs to be done? The email on OAuth meeting notes on -05 (with updates) said: 6.1.1. - describing the WWW-Authenticate response header - Discovery needed for various elements Yes. That's for the discovery draft. A wiki page on Future OpenID Technical Requirements http://wiki.openid.net/Future-OpenID-Technical-Requirements says: 6) IdP Discovery * Much of this will be covered by OAuth2 Discovery, however OIC may need to define OpenID specific features. ... 17) Simpler discovery * See Eran's OAuth Discovery proposal There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: expired, marked as obsolete by its author, discouraged from implementing, no update is expected, replaced by the OAuth 2.0 effort. I know I should write a discovery draft myself. -- James Manger ___ 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] OAuth discovery draft?
No objections on my part. I would rather have a smaller core spec with features that everyone agrees on. BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-authenticate's semantics in the context of a 401. It's unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The reason I care about this is that I think it makes sense that if someone wants to talk to an endpoint they know supports OAuth and need to know where their token issuer location is they would want to fire off an OPTIONS request to the resource and find out from the response where the issuer is and what realm is being used. It seems to me that the simplest way to solve this problem is to just return www-authenticate on a 200 response to an OPTIONS request. Thoughts? Thanks, Yaron From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, June 23, 2010 11:04 AM To: Yaron Goland; James Manger; OAuth WG Subject: Re: OAuth discovery draft? I think the core work is pretty stable now, unlike the discovery bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perhaps consider merging them later on when they reach an equal level of stability. But overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, Yaron Goland yar...@microsoft.com wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article. [2] I define 'full delegation' as User X of Service Y grants permission Z to User A of Service B. Currently OAuth requires X == A. In the future I hope to see extensions to OAuth that enable what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X==A restriction. It simplifies a whole host of issues and satisfies a really important use case. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, June 21, 2010 9:50 PM To: Manger, James H; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth discovery draft? Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next. EHL -Original Message- From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Monday, June 21, 2010 8:03 PM To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: OAuth discovery draft? Eran, There have been a few mentions recently of an OAuth discovery draft. Is there any such draft yet, or is this just a part that we know needs to be done? The email on OAuth meeting notes on -05 (with updates) said: 6.1.1. - describing the WWW-Authenticate response header - Discovery needed for various elements Yes. That's for the discovery draft. A wiki page on Future OpenID Technical Requirements http://wiki.openid.net/Future-OpenID-Technical-Requirements says: 6) IdP Discovery * Much of this will be covered by OAuth2 Discovery, however OIC may need to define OpenID specific features. ... 17) Simpler discovery * See Eran's OAuth Discovery proposal There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: expired, marked as obsolete by its author, discouraged from implementing, no update is expected, replaced by the OAuth 2.0 effort. I know I should write a discovery draft myself. -- James Manger ___ 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] Extensibility for OAuth?
Thanks Hannes. Great list of to-do items for the WG :) -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, June 23, 2010 2:08 AM This is probably the most important item were people will want to write extensions for. Currently, we have the following onces in the document: 1) Web Server 2) User Agent 3) Native Application 4) Autonomous Note that the actual profile identifiers aren't clearly listed in the document at the moment (or are inconsistent, such as user_agent and user-agent for the user agent profile). Is the plan to have a separate document for each profile? I'm assuming that we are all waiting for the draft-oath-v2 to stabilize (ps. it's gone from version 05 to 08 in a matter of 2-3 weeks, and now going to 09). We need to lock-down, I think. Need to distinguish between major/significant changes to minor/typo fixes. An open question might be whether there is a possibility for an extension (other than a new profile) to define an optional parameter that may get used with an existing profile. Note that at the moment there is no registry for parameters. It depends on what meaning of profile and extension. If the optional parameter is used in one of the profiles (use-cases) only, then it should not be place into the core draft-oauth-v2. If the optional parameter ends-up being used in all the profiles (use-cases), then add it to the core. I think this is where you draw the line (otherwise all sorts of weird and wonderful parameters ends-up in the core draft). /thomas/ smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth discovery draft?
Hi Yaron, I think delegation is a great idea/feature that should be added or OAuth (as I suggested in the kerberos-oauth draft). In the Kerberos world, it has been a very important feature (a life saver). In your example, when Yochi wants to terminate the delegation she gave to Leon, how does Yochi do this? Also, would it be possible for Yochi to delegate to another system (not a human user) to do things for her. For example, give delegation to a 3rd party service/system to (a) regularly fetch Yochi's Saturday/Sunday schedule from Yahoo Calendar, and then (b) publish it to FaceBook say. /thomas/ -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron Goland Sent: Wednesday, June 23, 2010 2:00 PM To: Eran Hammer-Lahav; Manger, James H; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth discovery draft? I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article. [2] I define 'full delegation' as User X of Service Y grants permission Z to User A of Service B. Currently OAuth requires X == A. In the future I hope to see extensions to OAuth that enable what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X==A restriction. It simplifies a whole host of issues and satisfies a really important use case. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, June 21, 2010 9:50 PM To: Manger, James H; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth discovery draft? Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next. EHL -Original Message- From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Monday, June 21, 2010 8:03 PM To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: OAuth discovery draft? Eran, There have been a few mentions recently of an OAuth discovery draft. Is there any such draft yet, or is this just a part that we know needs to be done? The email on OAuth meeting notes on -05 (with updates) said: 6.1.1. - describing the WWW-Authenticate response header - Discovery needed for various elements Yes. That's for the discovery draft. A wiki page on Future OpenID Technical Requirements http://wiki.openid.net/Future-OpenID-Technical-Requirements says: 6) IdP Discovery * Much of this will be covered by OAuth2 Discovery, however OIC may need to define OpenID specific features. … 17) Simpler discovery * See Eran's OAuth Discovery proposal There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: expired, marked as obsolete by its author, discouraged from implementing, no update is expected, replaced by the OAuth 2.0 effort. I know I should write a discovery draft myself. -- James Manger ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
