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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Sihb Attribute Release. Was: Shib & SAML presentation

Short return Marlena,


>>Regarding attribute release, I have some problems understanding
>>the Shib model. Does the destination (using SAML-terminology)
>>indicate what attributes it wants the source to release? At least
>>that seems like the most straight-forward way to do things.

>No, it doesn't.  It asks for all authZ attributes.  It gets only
>those that have been designated as releasable to it.
>   This topic was the subject of much debate within Shibb.
>I argued (apparently persuasively at the time) that if
>a destination asked for specific attributes there was an "implied
>promised" that release of those attributes (e.g "name")
>would result in access.  This seems to me to be a way
>to fool the user into releasing information.

In Sweden we say: "No matter what you do,
your butt stays on the rear".  With that I would say
that this solution have another problem which
is buried in the word "designated". 

Personally, I don't see any problem with selective attribute
requests, as long as AA "policy-settings" still can enforce requests
to be as "designated".  In general I prefer systems, where
policy can be set locally, rather than be hard-coded into protocols.

Due to the fact that real-world user-experience of systems like
Shib currently is fairly limited, I would at least consider a
redesign "just in case" it turns out that selective attribute
release indeed is both practical and useful.

Anders R

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

Powered by eList eXpress LLC