On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> This suggests we need to rethink our goal of interop and replace it with > library re-use. > > To me interop means that a client can interact with an unknown server by > simply speaking the protocol (the way an email can be delivered to any > server). Library re-use means that we define a set of configuration values > (client identifier, endpoints, cryptographic algorithms, scope, realm > policy, etc.) and once those are manually set (or via a discovery > specification that is completely out of scope) to make the library work. > > If we are not going to enable a client to access a protected resource > hosted by an unfamiliar server, we need to stop pretending this (alone) is > about interop. In other words, if we take this approach we are mandating > paperwork to make the protocol work, at least based on this single > specification. We can also drop advertising the authorization and token > endpoints in a 401 or really *any* parameter in a WWW-Authenticate response. > In my case, the proposed "bucket of opaque strings separated by spaces" does enable a client to access protected resources without knowing the details of Iron Money’s permission system. In 1.0, there was no set way of doing scope/permissions, which led me to a custom solution in which it’s not possible to access any protected resources without reading the documentation. With scope, the client wouldn’t need to know anything about the permission system; Iron Money could simply reply with the required scope values to access the resource. It seems as if this would also fit Facebook’s requirements, and I’m guessing this would fit the bill for most service providers as well. -Chasen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
