Hi,
A few questions we should answer before moving forward. Considering *your* use
cases and reasons for being here:
1. Why are you here?
I'm interested to learn about status and directions of upcomming OAuth
2.0 standard and to contribute my experiences with token based web
service security infrastructures.
What are you trying to solve that is not already addressed by existing
specifications (OAuth 1.0a, WRAP, etc)?
I would appreciate improved support for environments with central
authorization services and an "open triangle" style architecture (no
direct communication between web service and authorization server) .
OAuth 1.0a requires the protected resource to know consumer key and
secret, which is a security issue in our environment (central
authorization server, various services exposing protected resources
outside of our control). It should be sufficent to use token related
data in order to verify a token (or a message carrying the token,
respectively).
Just passing the token (bearer tokens) to a service should be an option
(typically over HTTPS).
It is difficult to revoke access tokens in our environment. I see the
following options:
a) Force the protected resource to check the token validity on each
request (requires remote calls - imperformant)
b) Push revocations to all services (complex)
c) Use a combination of long (months)- and short-living
(minutes-hours) tokens, long-living tokens are exchanged for short
living tokens, which in turn are used for service invocation. The
revocation is checked by the authorization server when issuing
short-living tokens.
The coming OAuth spec should support option (c)
2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point?
Something else?
draft-hammer-http-token-auth + WRAP
3. If we start from draft-hammer-oauth, what needs to change to turn it into
OAuth 2.0?
4. If we start from draft-hardt-oauth, what needs to change to turn it into
OAuth 2.0?
authorization servers should optionally issue token secrets in order to
support message signing.
5. Do you think the approach of working first on 'how to use a token' and then
on 'how to get a token' is right?
Both topics interdependent on each other, so building the big picture
first and elaborate the specification in two steps later on might be better
6. Should we go back to working on a single specification?
yes.
7. Do you think the protocol should include a signature-based authentication
scheme?
yes.
regards,
Torsten.
EHL
_______________________________________________
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
