that's pretty big! Can you please explain what kind of client you
authenticate with such assertions? They must contain hundreds of
attributes.
regards,
Torsten.
Zitat von Yaron Goland :
We regularly deal with SAML assertions that easily go into the 100s
of K. This is far more than most HT
Hi Eran,
what about token revocation? Will you include it?
regards,
Torsten.
Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav:
Draft -09 is now posted. Main changes include:
o Fixed typos, editorial changes. Thanks to Dick for his useful feedback.
o Added token expiration example.
o Added
That's a good point :) We may want to allow batch exchanges for an upgrade
flow, but you're right, then that doesn't really apply here.
On Jun 29, 2010, at 6:50 PM, Marius Scurtescu wrote:
> On Tue, Jun 29, 2010 at 6:30 PM, Luke Shepard wrote:
>> One reason is that you may want to exchange toke
This is configurable in IIS, Apache and Nginx but the default ranges from 4k to
16k.
Don't know if there are issues with buffer sizes on the client side.
On Jun 29, 2010, at 5:14 PM, Eran Hammer-Lahav wrote:
> More precisely, what are the actual deployed limits on HTTP *request* headers
> in
Yaron,
[Sorry I didn't see your response before sending my previous reply]
> SAML assertions routinely run into the 10s and even 100s of K.
> This exceeds the practical limit that most HTTP servers and proxies
> put on the size of the HTTP request headers they are willing to accept.
> So we canno
On Tue, Jun 29, 2010 at 6:30 PM, Luke Shepard wrote:
> One reason is that you may want to exchange tokens in a batch, whereas you
> typically can only sign requests individually.
How does the assertion grant type help in this case? As far as I can
tell this also allows you to exchange only one t
One reason is that you may want to exchange tokens in a batch, whereas you
typically can only sign requests individually.
On Jun 29, 2010, at 6:12 PM, Marius Scurtescu wrote:
> On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav
> wrote:
>>
>> The assertion grant type is really the grant type
On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav wrote:
>
> The assertion grant type is really the grant type extension point. Libraries
> should treat it as a way to support custom grant types. One of the things I
> would like to see someone draft is how to use OAuth 1.0 tokens to obtain
> O
More precisely, what are the actual deployed limits on HTTP *request* headers
in popular HTTP servers like Apache and IIS, and in popular client platform
likely to use this size assertions?
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Marius,
>> For instance, why not define a SAML HTTP authentication mechanism:
>>
>> Authorization: SAML a=
> This came up in another thread, but SAML assertions could be too large
> to be passed through an HTTP header. Other than that, your suggestion
> really simplifies things.
What are the
Hi everybody,
I updated the PHP library to include the changes in draft v9; hopefully I
read everything correctly. Feedback always welcome!
I also added a sample PHP Data Objects (PDO) implementation, so you can see
how it'd work with MySQL, MSSQL, etc.
Blog: http://www.opendining.net/category/
Personally I think we should go with #2.
Those who need 'mandatory to implement' extensions should do exactly what Eran
suggested and implement the extension in a way that breaks the core syntax so
they are guaranteed that those who don't support the extension will fail.
It is. 401 without it is not.
The discovery spec should spell out how to include it with a 200 response when
additional, private data is available.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron
Goland
Sent: Tuesday, June 29, 2010 12:28 PM
To: William Mills
This then goes back to one of my original posts which is - Is www-authenticate
legal on a non-401 response? I honestly don't know.
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Monday, June 28, 2010 3:30 PM
To: Yaron Goland; Torsten Lodderstedt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] OAuth
SAML assertions routinely run into the 10s and even 100s of K. This exceeds the
practical limit that most HTTP servers and proxies put on the size of the HTTP
request headers they are willing to accept. So we cannot rely on the HTTP
authorization header as a means of transporting SAML assertions
On Mon, Jun 28, 2010 at 9:37 PM, Manger, James H
wrote:
>
> For instance, why not define a SAML HTTP authentication mechanism:
>
> Authorization: SAML a=
This came up in another thread, but SAML assertions could be too large
to be passed through an HTTP header. Other than that, your suggestion
> -Original Message-
> From: pel...@gmail.com [mailto:pel...@gmail.com] On Behalf Of Pelle
> Braendgaard
> Sent: Tuesday, June 29, 2010 7:43 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Draft -09
>
> I found one small error in 3.1 for the "code" pa
I found one small error in 3.1 for the "code" parameter. It mistakenly
says "token" and not "code":
http://r6.sharedcopy.com/6bnqq8v
Anyway I hadn't seen any of the changes since 2.05 which I just
implemented for the Ruby on Rails OAuth Plugin and I have to say the
changes look great. I will have
For editorial feedback, I am going to try something new and use SharedCopy.com
(no install required).
Try it out at: http://r6.sharedcopy.com/6bnqq8v
If this doesn't work, I'll let people know and cancel it.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
H
19 matches
Mail list logo
