Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

But in federation scenarios the client credentials are an assertion.

For example, Microsoft has a service called Dallas that lets entities purchase access to proprietary data feeds. A common scenario we run into with Dallas is that a company will purchase access to a feed for its employees. But the company doesn't want to have to individually specify to Dallas who can and cannot use the feed. Instead they want to agree on a key with Dallas and use that key to sign assertions sent to Dallas saying "let this person in". The OAuth flow would be:

1. A Dallas client of an employee of 'the company' issues a request to 'the company's ticket issuer asking for a security token it can send to Dallas.
2. 'The Company's ticket issuer generates a signed assertion stating that the bearer has the right to use 'The Company's subscription to a particular feed.
3. The Dallas client then forwards that security token to Dallas's ticket issuer asking for an access token to actually talk to Dallas's front end.
4. Dallas validates the security token (e.g. checks the signature, makes sure it has the right claims, etc.) and if successful then issues an access token to the Dallas client.

So in step 3 the client credential was a full-fledged security token of potentially arbitrary size.

BTW, just to make sure I'm properly following along, we are talking about section 3.9?

		Yaron

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Tuesday, May 11, 2010 4:37 PM
> To: Yaron Goland; Torsten Lodderstedt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> No one was suggesting putting the assertion in the header. Just the client
> credentials...
> 
> EHL
> 
> > -----Original Message-----
> > From: Yaron Goland [mailto:yarong@microsoft.com]
> > Sent: Tuesday, May 11, 2010 4:24 PM
> > To: Torsten Lodderstedt
> > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> >
> > Actually it's server side that's the problem. Many servers limit the
> > size of the HTTP request headers they will accept. Apache 2.2, for
> > example, uses the LimitRequestFieldSize Directive
> > (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is
> > 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML
> > assertions can easily clock in at 30 or 40k without even trying.
> >
> > So as a practical matter we need a way to allow clients to assert
> > their right to a token using the request body so as to not need to
> > artificially limit the size of the token that is being submitted.
> >
> > 		Yaron
> >
> > > -----Original Message-----
> > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> > > Sent: Monday, May 10, 2010 10:47 PM
> > > To: Yaron Goland
> > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> > >
> > > Am 11.05.2010 01:43, schrieb Yaron Goland:
> > > >
> > > >> ---
> > > >>
> > > >> 2. Client Authentication (in flows)
> > > >>
> > > >> How should the client authenticate when making token requests?
> > > >> The current draft defines special request parameters for sending
> > > >> client credentials. Some have argued that this is not the correct
> > > >> way, and that the client should be using existing HTTP
> > > >> authentication schemes to accomplish that such as Basic.
> > > >>
> > > >> A. Client authenticates by sending its credentials using special
> > > >> parameters (current draft) B. Client authenticated by using HTTP
> > > >> Basic (or other schemes supported by the server such as Digest)
> > > >>
> > > >>
> > > > [Yaron Goland] A is needed at a minimum because there are physical
> > > limitations to how many bytes can go into an authorization header.
> > > >
> > >
> > > As far as I know, 4KB is the minimum size for headers that must be
> > > supported by user agents, which should suffice from my point of view.
> > > Moreover, other HTTP authentication mechanisms need much more than
> > > 4KB, For example, SPNEGO authentication headers can be up to 12392
> > bytes.
> > >
> > > regards,
> > > Torsten.
> > >
> > > >> _______________________________________________
> > > >> 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
> > > >
> > >
> > >
> 