OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> identifier in such a case is either
> global (assumed to be useful to any SP but a privacy no-no), or
> meaningless
> to the SP (a handle accompanied by other data)
Sorry, perhaps I wasn't clear on this - it's the meaningless handle that
will be used. If an SP wants your identity to access services then your
privacy is breached. Unless you decide to block release of privacy
releasing attributes, in which case you won't get access.

Not sure if I mentioned it but if an IdP is willing to respond to these
"avatar" attribute requests - the avatar is anonymous as far as the SP is
concerned. It only resolves to an identifiable user when the attributes
come back. Perhaps the IdP needs a new set of attributes or mapped
attributes that only the avatar can use. Like you said, that's policy.


happy hols if you're taking any :)


Alistair Young
Senior Software Engineer
UHI@Sabhal Mr Ostaig
Isle of Skye

>> I didn't say the IdP doesn't know the SP, I said (or meant to say)
>> that the IdP may not know the SP in advance, so it can't issue an
>> assertion targeted at a specific SP.  (I don't dare try to explain
>> this further, otherwise this thread will deteriorate into oblivion :)
> No, I get you. My point was that the identifier in such a case is either
> global (assumed to be useful to any SP but a privacy no-no), or
> meaningless
> to the SP (a handle accompanied by other data). There's no reason an IdP
> couldn't issue a handle that was usable by anybody that happened to get
> the
> token, and it would probably be willing to respond to queries on that
> basis
> for as long as the token was valid. All of that is just policy.
> I said elsewhere that a transient handle was pair-wise, but I was sloppy.
> It's not. It's issued for some set of relying parties, and how big that
> set
> is is not dictated by any spec, it's IdP policy.
>> > Anything you want to do is going to require new functionality. Sorry,
> that's
>> > the way it is. But that functionality won't have much to do with
>> > identifiers, and that's my only point.
>> And that is our fundamental point of disagreement...I'll leave it at
>> that.
> What I meant (but you might still disagree with) was that it doesn't
> impact
> the *specifications* with respect to identifiers. Obviously there is lots
> of
> new functionality in the spec (encrypted IDs, NameIDMapping) that would
> pertain to how identifiers would be used/chosen/issued. And new code
> needed
> for all of that.
> My claim is that the basics already spec'd are sufficient to design
> profiles
> involving many actors in different scenarios, but one thing they have in
> common is probably a reliance on an IdP or something like it to manage and
> supply crosswalks between entities that share only a relationship with it.
> -- 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@lists.oasis-open.org
> 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/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]