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] | [List Home]

Subject: RE: [security-services] Groups - draft-sstc-nameid-05.pdf uploaded

Scott wrote, in reply to Michael: 

> Item 2:
> The document specifically states that federations "must" be 
> explicitly consented to by the user.

John wrote the original requirements based on Liberty. Not even they
*really* treat this as a MUST. Politically, any standard that tries to
address this area runs afoul of some very serious privacy legislation.
Realistically, not every deployment has the same requirements.

That's why it ultimately belongs in the implementation guidelines document,
which is why I think SAML needs one.

[JL] I don't believe that the requirements text as drafted actually mandates
per-instance explicit user consent.  Rather, lines 155-157 of nameid-06
state: "... no federation shall be established without approval by the
principal's authentication authority, which is relied upon to act in
accordance with a policy accepted by the principal, unless the deployment
specifically obviates the need for such privacy considerations."  For the
case of in-band federations via specified protocols, I believe that
implementations should certainly be able to support policies where
principals explicitly approve each federation, but other policies where the
authentication authority acts autonomously on the principal's behalf may
also be possible.  Further, the text wasn't intended to exclude out-of-band
bulk federations, which may be useful for many enterprise cases and for
which any consent would also have to be obtained out-of-band. 


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