I think we gonna need additional end points anyway, e.g. for token
revocation. So why not use another endpoint for that purpose? That way
the tokens endpoint is not overloaded to much.
regards,
Torsten.
Am 16.07.2010 18:48, schrieb Justin Richer:
The current proposal for a 1.0->2.0 upgrade flow is to use the assertion
profile and pass the OAuth token in there. Instead, one could create an
endpoint that speaks the 1.0 protocol fully, signatures and client
secrets and everything, but issues 2.0 tokens, JSON and all. It's a
hybridized endpoint also, but put together with the opposite pieces. In
both cases, you put a 1.0 token in one end and get a 2.0 token out the
other. But in this case, the request being made is a completely vanilla
OAuth 1.0 protected resource access request.
Does this really need a separate endpoint, or can we extend the
grant_type options to include "oath1.0" in an extension? I know that
extensions aren't currently allowed to make new grant_types -- I think
they should be able to and and proposing that we allow that extension
point. I dislike the reasoning of "just cram it all into an assertion to
extend", since it doesn't allow for clients to separate out their
parameters easily.
-- Justin
_______________________________________________
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
