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 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
