Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com: On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell bcampb...@pingidentity.com wrote: There seem to be two potential arguments against it - the burden of tracking the state and the potential that it's unnecessarily restrictive. I don't personally see either as being a major issue but would like to hear from folks if they feel differently. I could change the language from a MUST to a SHOULD or MAY to allow for more flexibility at deployment/development time? That would slightly increase the opportunity for interop problems but I don't think it's really much of a concern. MAY seems reasonable to me. +1 ___ 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 server id needed?
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 of resource server, as an added differentiator for the scope (a namespace, if you will)? So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to. The auth server that serves both resource servers could have two end user authorization endpoints: http://auth.server.org/authorize?resourceserver=1 http://auth.server.org/authorize?resourceserver=2 And that way the auth server knows exactly what the client needs. The only scenario this doesn't allow for is for a user to authorize a client's access to /both/ resource servers in one redirect. If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring: rs1:photo:read rs2:photo:read Which would serve a similar purpose. -- 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 On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: no one else in the group having an opinion on this topic? Am 15.07.2010 20:14, schrieb Marius Scurtescu: On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: As I have written in my reply to Marius's posting. I'm fine with including server ids in scopes. But this requires a definition of the scope's syntax and semantics in the spec. Otherwise, scope interpretation (and server identification) will be deployment specific. Sure, it is deployment specific, but why is that an issue? In your case, the authz server and all the resource servers are managed by the same organization, right? Do clients need to be aware of the actual resource server? You can probably create a separate spec that defines scope syntax for this purpose, if really needed. Does it have to be in core? Marius Solving the challenge I described in a deployment specific way is not an 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
Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
+1 on MAY; (+0.3 on SHOULD). Igor Torsten Lodderstedt wrote: Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com: On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell bcampb...@pingidentity.com wrote: There seem to be two potential arguments against it - the burden of tracking the state and the potential that it's unnecessarily restrictive. I don't personally see either as being a major issue but would like to hear from folks if they feel differently. I could change the language from a MUST to a SHOULD or MAY to allow for more flexibility at deployment/development time? That would slightly increase the opportunity for interop problems but I don't think it's really much of a concern. MAY seems reasonable to me. +1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
MAY it is. Thanks On Jul 28, 2010 4:06 AM, Igor Faynberg igor.faynb...@alcatel-lucent.com wrote: +1 on MAY; (+0.3 on SHOULD). Igor Torsten Lodderstedt wrote: Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com: ... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] On the discovery of the OAuth Signature
On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura sakim...@gmail.com wrote:
Hi.
Currently, the discovery document would have something like:
{
verification_keys: {
key1:RSA.ALqcwR...,
key2:X509.certificate
}
}
It defines RSA and X509. Could we define a third type certs_url that
points to the
file that stores PEM format certificates (chain as well)?
I'm a bit hesitant to add more formats, since the client libraries would
have to support all of them. I'd be more comfortable actually replacing,
say, the X509.certificate version with this indirection.
One question, though: in my proposal, I'm saying that the validity of the
public key is controlled by the caching directives of this document. I.e.,
if you fetch this document, it has a key in it, and it says you can cache
this for 24 hours, then it's ok to use the public keys in there for the
next 24 hours. If you use self-signed certs (the X509.certificate
version), you're supposed to ignore the not-before and not-after fields in
there. How does that work for this additional level of indirection? Let's
say the server info document is cacheable for 10 hours, the PEM you
download from there says that it can be cached for 24 hours, and the
not-after field in the cert says that it's valid for another week. Which of
those takes precedence?
Dirk.
=nat
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Protected feeds
Folks interested in protected feeds may be interested in UMA's solution, which
proposes mechanisms to demand claims from the requesting side based on
user-specified policyon the authorizing server side. An example of
UMA-protected resources that require agreement to terms can be seen in the
SMART project documented here (if you want, you can sign up to take part in a
UX study they're conducting right now:
http://smartjisc.wordpress.com/
More general info about UMA is here:
http://kantarainitiative.org/confluence/display/uma/Home
Note that UMA is OAuth-based and tries to make its profiling and extensions as
small as possible to achieve its requirements, but I suspect its requirements
list is a bit longer/more comprehensive than what is described below.
Eve
On 28 Jul 2010, at 1:28 PM, Darren Bounds wrote:
Please excuse the cross posting.
Following the Federated Social Web Summit in Portland a couple weeks
ago, there has been a lot of chatter around protected feeds and how
they'll function to achieve SWAT0
(http://federatedsocialweb.net/wiki/SWAT0). Protected feed
subscriptions are clearly an important component of DiSo and necessary
for features like remote follow/friending.
During the summit Brett Stlakin published and discussed a document
(http://tinyurl.com/push-oauth) where he proposes one technique for
how OAuth may be used with PuSH to achieve the requirements. The
proposal details an OAuth 2 flow (in addition to OAuth 1x) for
handling a usecase that involves ToS acknowledgement before a
protected feed subscription may be granted. The flow is essentially
the web server client profile combined with the assertion grant type.
While the flow will work and achieve the goals it also has a
fundamental need for a user-agent redirect, something that not all
providers may desire or require.
What I'd like to propose is a variant of the assertion grant type that
would make the user-agent redirect optional. The goal here was to stay
within the bounds of the current spec where ever possible. That said;
it may be desirable to break this out into it's own client profile.
The flow detailed below is using the OAuth 2 scenario described in
Brett's document (http://tinyurl.com/push-oauth).
1) cliqset.com would like to request an access token from google.com.
Sends a request with grant_type=assertion.
Request:
POST /token HTTP/1.1
Host: google.com
Content-Type: application/x-www-form-urlencoded
grant_type=assertionassertion_type=http://webfinger.org/;
assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ==
The assertion value in the request is a Base64 encoded JSON string
with two properties, uri and magic_signature. Example:
{
uri: acct:dbou...@cliqset.com,
magic_signature: asdlkklafsdjkldsfjlkj=
}
Response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
access_token:supersecrettoken
precondition_uri,http://google.com/oauth/authorize?state=opaquevalue
code,myrandomcode123
}
The access token response introduces two new optional properties:
precondition_uri and code
The existence of a precondition_uri means the consumer will be
required to redirect the user to this uri in order to complete the
activation of the provided access token.
The precondition_uri resource has the same characteristics of the
OAuth 2.0 Web Server client profile with the ‘state’ property being
used to maintain state between the assertion request and the user
redirect. Successful acknowledgement of the precondition results in a
302 response with the code provided in the assertion response (see
example below).
The existence of a code is required upon the presence of a precondition_uri.
If no precondition_uri is provided, the access token should be
considered active and immediately usable barring any provider specific
back-end authorization (e.g. user acceptance of remote follow).
2) access token received optional precondition_uri. Issuing user
redirect to precondition_uri with redirect_uri.
Request:
GET
/oauth/authorize?state=opaquevalueresponse_type=tokenclient_id=acct:dbou...@cliqset.comredirect_uri=http://cliqset.com/callback
HTTP/1.1
Host: google.com
User acknowledges the precondition. This could be any number of
activities, including authenticating.
Response:
HTTP/1.1 302 Found
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
Re: [OAUTH-WG] resource server id needed?
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 of resource server, as an added differentiator for the scope (a namespace, if you will)? So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to. The auth server that serves both resource servers could have two end user authorization endpoints: http://auth.server.org/authorize?resourceserver=1 http://auth.server.org/authorize?resourceserver=2 And that way the auth server knows exactly what the client needs. The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect. If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring: rs1:photo:read rs2:photo:read Which would serve a similar purpose. -- 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 On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: no one else in the group having an opinion on this topic? Am 15.07.2010 20:14, schrieb Marius Scurtescu: On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: As I have written in my reply to Marius's posting. I'm fine with including server ids in scopes. But this requires a definition of the scope's syntax and semantics in the spec. Otherwise, scope interpretation (and server identification) will be deployment specific. Sure, it is deployment specific, but why is that an issue? In your case, the authz server and all the resource servers are managed by the same organization, right? Do clients need to be aware of the actual resource server? You can probably create a separate spec that defines scope syntax for this purpose, if really needed. Does it have to be in core? Marius Solving the challenge I described in a deployment specific way is not an 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
