I'm waiting to see what Brian has in mind for signatures. If we keep the OAuth
1.0a signature flow, we will need to deal with string encoding of some sorts.
The current limitation has signature in mind, not transmitting requests.
But either way, since assertions have unique structures, it is imp
On Fri, Apr 2, 2010 at 12:00 PM, Eran Hammer-Lahav wrote:
> Because of how we send parameters. Most of the problems we had with
> 1.0 involved encoding issues. We just need to find a good way of
> explaining it.
>
> These are the characters allowed in Uris and form encoded bodies.
Of course, but
Because of how we send parameters. Most of the problems we had with
1.0 involved encoding issues. We just need to find a good way of
explaining it.
These are the characters allowed in Uris and form encoded bodies.
EHL
On Apr 2, 2010, at 12:35, "Marius Scurtescu"
wrote:
> On Thu, Apr 1, 2
ce we have something concrete.
thanks
-cmort
From: Eran Hammer-Lahav [e...@hueniverse.com]
Sent: Friday, April 02, 2010 9:03 AM
To: Chuck Mortimore
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)
The pr
On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav wrote:
> The current draft allows the following characters:
>
> value-char = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"
>
> Which means a utf-8 string will need to be encoded somehow. Should it be
> percent-encoded? Something else?
Why do we
_
> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of
> Eran Hammer-Lahav [e...@hueniverse.com]
> Sent: Thursday, April 01, 2010 9:54 PM
> To: Marius Scurtescu
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress
>
the weekend and present it to the list.
-cmort
From: Eran Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, April 01, 2010 9:02 PM
To: Brian Eaton
Cc: Chuck Mortimore; OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)
cmort
From: Eran Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, April 01, 2010 9:02 PM
To: Brian Eaton
Cc: Chuck Mortimore; OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)
This boils down to: if the flow cannot be used wi
n.
-cmort
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, April 01, 2010 9:54 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progr
Assertion Flow (was: Draft progress update)
The current draft allows the following characters:
value-char = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"
Which means a utf-8 string will need to be encoded somehow. Should it be
percent-encoded?
The current draft allows the following characters:
value-char = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"
Which means a utf-8 string will need to be encoded somehow. Should it be
percent-encoded? Something else?
EHL
On 4/1/10 10:00 PM, "Marius Scurtescu" wrote:
On Thu, Apr 1, 2010 at 9
On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav wrote:
> What is the assertion format? Binary? XML? Should the library encode it? Is
> the application using the library responsible for providing it with a
> URI-safe string?
UTF-8 string I guess, the rest should not matter.
Marius
_
What is the assertion format? Binary? XML? Should the library encode it? Is the
application using the library responsible for providing it with a URI-safe
string?
EHL
On 4/1/10 9:45 PM, "Marius Scurtescu" wrote:
On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav wrote:
> But providing a half
On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav wrote:
> But providing a half baked flow that is short enough to just replicate where
> needed and cannot be fully implemented by generic libraries doesn’t really
> offer much.
I think this is similar to the scope parameter argument, that
librarie
This boils down to: if the flow cannot be used without further profile, and it
is less than a page long, what's the value of putting it in the specification,
as opposed to a fully specified extension? Or the alternative to provide one
fully specified flow using the most common type of assertions
On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav wrote:
> Are they profiling a half page spec?
The spec is 66 pages long. But the widely used pieces are quite a bit
shorter. =)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf
Are they profiling a half page spec?
EHL
On Apr 1, 2010, at 19:53, "Brian Eaton" wrote:
> On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore
> wrote:
>> Flexibility. If we lock Oauth2 down to one specific specific
>> Assertion, it
>> becomes unusable for other assertion formats. Those asser
On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore
wrote:
> Flexibility. If we lock Oauth2 down to one specific specific Assertion, it
> becomes unusable for other assertion formats. Those assertion formats will
> evolve anyways.
Yep. The SAML Web SSO profiles are living proof that something ca
Flexibility. If we lock Oauth2 down to one specific specific Assertion, it
becomes unusable for other assertion formats. Those assertion formats will
evolve anyways.Looked at somewhat differently, if there is only 1 assertion
format supported by the spec, then what is the point of the as
What is the value of an under specified flow? Especially one as short and
simple as this one?
My point is that if the flow requires further profiling to be useful, the whole
thing does belong in the core spec. It is short enough to be cut and paste into
another spec repeatedly for each well spe
As you've pointed out, the current text is in somewhat of a grey area. It's
either over specified ( remove any reference to SAML ) or underspecified ( be
very explicit about exactly what is expected )
I'd advocate that the core spec is left under-specified. If we're
prescriptive on the exac
On Thu, Apr 1, 2010 at 12:24 PM, Eran Hammer-Lahav wrote:
> A generic assertion flow is too under-specified to be included.
Can you please give some more details, why is that?
For any assertion flow to work the client and the authorization server
must trust
each other, leaving the assertion form
A generic assertion flow is too under-specified to be included. If a SAML2
assertion flow isn't enough or useful, we should define what is and fully
specify it. The current text is still incomplete as it doesn't address how the
assertion should be encoded in the request.
EHL
On 4/1/10 11:21 A
Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".
The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?
Marius
On Wed, Mar 31, 2010 at 6:22
24 matches
Mail list logo
