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: [email protected] [[email protected]] On Behalf Of Eran
Hammer-Lahav [[email protected]]
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" <[email protected]> wrote:
On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
