Only HTTP headers may not be enough. In Yaron's proposal, the assertion could be a SAML assertion, and these could be too large for headers.
I think #1 makes sense. Marius On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > I would prefer (2) since authorization headers are the natural way to handle > authentication in HTTP. Different client credential mechanisms can be > represented by different authentication scheme (even custom-defined). HTTP > libraries typically have special support for handling such headers and it > keeps the authentication mechanism orthogonal of the API. Moreover, > authorization headers very well work together with status code 401 and > WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server > can easily signal what mechanisms (multiple WWW-Authenticate headers are > allowed in a single HTTP response) it accepts for a particular request. > > regards, > Torsten. > > Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > > Yaron Goland offered a proposal for an additional client credentials > mechanism based on assertion. His proposal raises the issue of > differentiating between the different kind of credentials used. When it > comes to access grant types, this group argued for being explicit and > providing a parameter declaring the grant type being used (even though it is > not technically necessary). > > > > While I don’t believe a grant or credential type parameter is needed – the > type can be deduced from the other parameters present – we now treat the > same requirement with a different solution. I think this creates a broken > environment for extensibility (which is my current focus). > > > > At the same time, introducing such a parameter can conflict with the > standard HTTP authentication mechanism. For example, a request containing > both “client_credentials_type=basic” and the HTTP Authorization header seems > odd. > > > > There are a few ways to address this: > > > > 1. Only use a type parameter when the credentials are passed using > parameters and not a header. > > 2. Only allow HTTP headers for authentication, while “grandfathering-in” the > client_secret parameter to simplify the most common current practice. > > 3. Leave is underspecified, relying on the presence of extension parameters > or authentication headers for other credentials types. > > > > Thoughts? > > > > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
