Agreed on Base64, however the SAML already specifies this at it's encoding for
web profiles, so we'll get the most reuse out of existing infrastructure by
using it.
I will work on an example - we should be able to make some sound decisions
about how best to deal with it once 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 problem with base64 (even the uri safe flavor) is the paddind
character (=) is not allowed without percent encoding. This gets messy
without clear encoding process.
The example below show that the profiles are likely to be much longer
than the flow itself, raising my question of whether it is really all
that useful to be included.
If we are going to keep this in the core spec we need a list of what a
profile must specify (just the items, not the actual details) and we
need an example. I can live with that.
Another option is to move it to a separate assertion flows spec which
will include a few generally useful profiles.
EHL
On Apr 2, 2010, at 10:45, "Chuck Mortimore"
<cmortim...@salesforce.com> wrote:
> The format would be specified by a profilie. For instance, a SAML
> profile might define:
>
> assertion_format=urn:oasis:names:tc:SAML:2.0:cm:bearer
> assertion={SAML 2 bearer assertion, optionally wrapped in a SAML
> response, Signature must cover the assertion and can be inherited
> from the Response signature, based64 encoded. Subject format and
> attribute statement left undefined and implementation specific}
>
> Some other implementation may want a SAML1.1 profile, or an
> Encrypted Assertion Profile, which would all be base64 encoded, but
> the details of the expected assertion would change. Someone may want
> to develop a Siteminder profile. In this case, a siteminder
> session token would be exchanged for an Oauth token. This would
> have a completely opaque format, and might be hex encode. Someone
> else might want to develop an x.509 profile. Etc, etc.
>
> It really wouldn't be up to conformant Oauth2 clients to support
> these profiles, or even the core assertion profile for that
> matter. As Marius points out, the method for obtaining/validating
> the assertions will be out of scope, and hence this is a specialized
> Oauth client/server you're dealing with by definition.
>
> -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 progress
> update)
>
> 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" <mscurte...@google.com> wrote:
>
> On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav
> <e...@hueniverse.com> 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
> libraries cannot really
> use an opaque scope. OAuth libraries will neither generate nor
> consume the
> assertions, the assertion itself can be opaque. The client
> application needs to
> obtain an assertion somehow, this is out of scope, then pass it to a
> library and
> the library can use it as is, pass it to the Authorization Server and
> deal with the
> response. Works perfectly fine IMO.
>
> Marius
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
