RE: [saml-dev] Legal issues around SAML

Alistar, Scott, 

We have cross paths some time ago, and have an inactive member of this
list-serv for some time, and your comment about legal issues caught my
eye.  

I am working on public/private partnership initiative that is taking on
the legal issues of information security (as one element), and thought
they might offer some assistance if you feel these issues are outside
the expertise of us engineers.  

Please frame your concerns and I will be glad to take this us with the
CxO Advisory Council.  Their common interest is Secure Information
Sharing architectures, and is being engaged by FBI, DOJ, DNI, DHS, and
DoD.  


John Weiler, E.D.
iECM Outreach Chair
CxO Advisory Council Secretariat 
SecurE-Biz Executive Summit Program Chair
Solution Architecture Integration Lab CTO
Interoperability Clearinghouse
(v) 703-768-4975
(c) 703-863-3766
(f) 703-765-9295
www.ichnet.org
www.secure-biz.net
 
-----Original Message-----
From: Alistair Young [mailto:alistair@xxxxxxxxxxxxx] 
Sent: Tuesday, November 29, 2005 6:23 PM
To: Scott Cantor
Cc: saml-dev@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [saml-dev] Subject confirmation.

Thanks Scott, it's getting clearer.

> What profiles spec?
saml-profiles-2.0-os

Under Holder of key it says:

"The holder of the key named "By-Tor" or the holder of the key named
"Snow
Dog" can confirm itself as the subject".

That's why I thought "proxy" as whatever entity has one of those keys
may
or may not "be" the subject (confirm itself as the subject).

So it seems that the SAML semantics are open to interpretation depending
on what profile is in use. They're context sensitive. By defining a new
profile you can redefine the semantics but within the global SAML core
context.

Just out of interest, was there any legal input to the SAML specs?

> Realistically, the answer to any question you ask could be "anything"
if
it doesn't violate explicit SAML core processing rules
I see what you mean now.

Alistair


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

>> Reading the profiles spec seems to suggest that
>> SubjectConfirmation is a means to "proxy" the "real" Subject?
>
> What profiles spec? And no, it doesn't mean only that. It could mean
that.
>
>> However, the asserting party can add additional information to the
>> assertion giving various third parties (attesting entities)
>> the right to "claim they are me"?
>
> If a profile defines that. No such profile currently exists. The
language
> you're talking about is intended to *allow* a profile to do so.
Nothing
> more
> or less.
>
>> i.e. in bearer in web sso:
>> "The bearer of the assertion [The Browser] can confirm itself as the
>> subject [Me]"
>
> Right, and web sso is a profile.
>
>> in holder of key, the asserting party is basically saying:
>>
>> "anyone who holds the key or certificate identified in the
>> SubjectConfirmationData can claim to be Subject" - subject to
>> conditions of course.
>
> It means "associated" with the subject. Nothing more or less. Only the
> profile can define what "associated" means.
>
>> Does that mean that, say, SPa can sign something in the assertion ir
got
>> from IdP before passing it on to SPb and SPb can use the
certficate/key
>> in
>> SubjectConfirmationData to verify that SPa indeed has the key
identified
>> in SubjectConfirmationData? If so, then SPb can assume that the
>> attesting
>> entity (SPa) has a relationship with the asserting party (IdP) via
it's
>> key, which is identified in SubjectConfirmationData?
>
> A relationship, yes. You're jumping from that to being explicit about
what
> the relationship is. Only a profile of use can do that.
>
> -- Scott
>
>


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
SAML OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
List archives: http://lists.oasis-open.org/archives/saml-dev/
Committee homepage: http://www.oasis-open.org/committees/security/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/