Re: [saml-dev] SAML, trust and WS.

["Alistair Young" <alistair@smo.uhi.ac.uk>]

> - In the following paragraph on page 2, it talks about trust between
> the VLE and the VFS when in fact it is the trust relationship between
> the VFS and the IdP that is important.  I don't believe the VFS need
> trust the VLE at all.  The latter is simply a transporter of signed
> assertions.
that bit of trust is for the VFS to lock down services to known clients,
if required. Perhaps it's overkill. In effect the VLE is identifying
itself to the VFS and trying to prove it's allowed to access the VFS
services.

If the VFS trusts the VLE then it can trust the IdP too, whose information
is being transmitted by the VLE to the VFS.

The VLE is saying "I'm the VLE and if you need attributes for the user on
whose behalf I'm working, here's their Subject and IdP location - if you,
VFS, need more attributes on the user, I don't care. Get them yourself.
All I care about is a return value or error from your service".

That's why I don't want transients as they'll just timeout. I'm trying
(quite unsuccessfully!) to describe a "digital avatar", almost, for the
user, generated by their IdP. It identifies who they are and where their
"home" is.

To compare with Scott's idea of an IdP giving a transient to an SPa for
transmission to SPb. The transient becomes the SAML avatar in the loopback
scenario. So it has to be a persistent identifier, that travels among
external entities.

It's really agents. Agents have owners (users) and if an agent was to
access something, VFS search say, it has the capability to say to the VFS.
"Here's my owner - go get their attributes then let me in".

The next step is how to define the SAML avatar. It will be SAML2.

Agents with SAML avatars... cybermugging... hmmm...

Alistair



-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig
Isle of Skye
Scotland

> On 12/20/05, Alistair Young <alistair@smo.uhi.ac.uk> wrote:
>>
>> http://www.weblogs.uhi.ac.uk/sm00ay/?p=164
>>
>> Is the document (at the foot of the page) any use to you? It's at a very
>> early stage so not sure which way it will go. We initially looked at the
>> contrained delegation profile but there are a few questions, outlined in
>> the
>> document.
>>
>> If you can point out any glaring errors in our approach, it would be
>> most
>> helpful!
>
> It's difficult to identify "errors" since the document doesn't get
> into much detail.  A couple of observations, however:
>
> - On page 2, it sounds as though the VLE binds its own key to the
> message but of course it is the IdP that should bind the key, not the
> VLE.  (See [Cantor 2005].)
>
> - In the following paragraph on page 2, it talks about trust between
> the VLE and the VFS when in fact it is the trust relationship between
> the VFS and the IdP that is important.  I don't believe the VFS need
> trust the VLE at all.  The latter is simply a transporter of signed
> assertions.
>
> - You mention "SAML Subject" a number of times, but I'll believe it
> when I see it (as the old saw goes :).
>
> - The basic thrust of the whitepaper seems to be attribute pull vs.
> push.  If you're going to advocate pull, you're going to have to deal
> with the name identifier issue.
>
> - Some of your arguments against push are good, others are not so
> good.  The claim of "unnecessary overhead" is not really an issue, I
> don't think.  The user would need to activate push (by clicking on a
> link in the VLE, for instance).  Anything else would be suspect.
>
> - Basic comment is...details, details, details, or rather the lack of
> details.  There's too much hand waving.
>
> - Are you thinking SAML 2.0 or SAML 1.1?  If SAML 2.0, what's the
> matter with [Cantor 2005].  If SAML 1.1, can you produce an example?
>
> Cheers,
> Tom
>