Am 16.07.2010 19:00, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
<[email protected]> wrote:
then we should put those use cases and requirements on the table and try to
find a solution fulfilling these different needs. That's what (from my point
of view) standard definition is all about.
What do you think?
Sounds fine to me. I don't think we could realistically target the
work for the core oauth spec. An extension would work well.
Why not?
And if an extension is the right place to define scope syntax and
semantics, then I would suggest to move the scope parameter(s) to that
extension, too. A scope parameter without a clear definition in the core
endangers interoperability.
For my future use cases, at any rate, the core oauth spec is fine.
the web-server flow and the user-agent flow are both compatible with
what I'd want to do.
Regarding relations between authz servers, resource server and clients,
we have the following requirements:
We definitely need support for deployments w/ 1 authz server, n
resources servers, and m clients. At least resource servers and clients
must be identifiable at the protocol level. I don't prefer a certain way
of resource server identification: dedicated server_ids, including the
server id within scopes or any other solution is acceptable.
We would like to see support for specifying permissions on resource
servers. I think scope would be the natural way of specifying them.
What do others think?
regards,
Torsten.
Cheers,
Brian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
