from my understanding, the assertion you explained in your scenario
represent the authorization of end-users (not client applications) to
access feeds. Thus I see them as a kind of user credentials and would
send them as request parameter. Authorization headers will be used for
client authentication only.
regards,
Torsten.
Am 13.05.2010 22:51, schrieb Yaron Goland:
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:e...@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:yar...@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:tors...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
