[WG-IDAssurance] [WG-P3] Towards a Unified Theory
Mark Lizar
mark at smartspecies.com
Fri Mar 11 12:55:32 EST 2011
I think it is important to identify the consent models in use and the
variations.
A consent model I would guess would include consent for all things the
RP/SP may collect about the user?
Unless there is an explicit opt-out/in with exceptions that state
otherwise. At this time I believe there to be a big hole needing
better consent models that are more granular and standardised.
- M
On 11 Mar 2011, at 15:20, John Bradley wrote:
> In general in SSO the IdP is not sending a explicit consent consent
> message.
>
> The IdP gathers consent from the user for returning the
> authentication assertion and some number of attributes.
> The consent is implicit in what the IdP returns.
>
> I think that scope is part of the question. Are we discussing just
> the identifier, the identifier and SSO attributes, or all things the
> RP/SP may collect about the user?
>
> John B.
> On 2011-03-11, at 12:13 PM, Jason Seto wrote:
>
>> for this discussion, are we specifically talking about consent as
>> it applies to the identity information that is being sent by the
>> IdP to the RP withing the message? too often i've seen a consent
>> topic derailed by different consents being combined into only one
>> "consent" which causes a lot of confusion.
>>
>> On Fri, Mar 11, 2011 at 10:00 AM, John Bradley <ve7jtb at ve7jtb.com>
>> wrote:
>> The idea with the consent indication in the authn request was to
>> allow the RP to collect the consent for the information release
>> before redirecting the user to the IdP. This needs a strong trust
>> relationship with the RP that may not exist in many cases.
>>
>> I like the wayf consent system. It makes the problem of
>> retrofitting the individual IdP much easier.
>> However the proxy itself creates a new point to trust and protect.
>> I don't know that it is a universal solution.
>>
>> The technical solutions will need to keep up with the policy.
>>
>> With information cards(RIP) we tried to build notice and consent
>> directly into the protocol.
>> That however created as many problems as it solved in many ways.
>>
>> John B.
>> On 2011-03-11, at 11:46 AM, David Simonsen wrote:
>>
>> > Hello John, Mark,
>> >
>> > Sorry for jumping into the discussion - please find comments in-
>> line:
>> >
>> > On Mar 11, 2011, at 2:58 PM, John Bradley wrote:
>> >> The only thing that talks about notice and consent in SAML is a
>> message that the SP can send to the IdP saying the user has already
>> consented. That is useful in some federations but a high level of
>> trust must exist with the SP/RP.
>> >
>> > IMHO consent to exchange of attributes must always happen
>> _before_ they are send to the SP.
>> > It does not make sense to ask the user for consent to data
>> exchange after the exchange has taken place.
>> > Please find a video presentation on user consent of how to
>> handle / manage user consents centrally (in hub-and-spoke
>> federations) at:
>> > http://wayf.dk/wayfweb/users'_consent_to_data_exchange.html in
>> the video archive: http://wayf.dk/wayfweb/video_archive.html
>> >
>> >> All of the user interface parts are outside of the spec. (With
>> the possible exception of the not widely used ECP client)
>> >>
>> >> It is common practice for access to attributes to be negotiated
>> directly between the IdP and the SP and sent by configuration eg
>> SP x gets some fixed list of attributes every time. Or a separate
>> attribute query is performed directly between the SP and IdP
>> without user involvement.
>> >>
>> >> This causes the user consent experience to be all over the place
>> with SAML.
>> >> In many cases there is no method of knowing what attributes the
>> RP/SP is asking for at the time of the user interacting with the IdP.
>> >>
>> >> SAML supports requesting the attributes as part of the authn
>> request. The FICAM SAML profile strongly encourages this.
>> >
>> > The question is fundamentally about negotiation power and
>> adherence to the principle of minimal disclosure (SPs typically
>> want more user information than needed).
>> >
>> > Federation operators may suggest attribute release policies
>> (ARP's) in the federations' metadata, but IdPs may be pressed to
>> deliver what the SP requests (because of low IdP negotiation power
>> in p2p setups).
>> > In hub-and-spoke federations, with central proxy IdPs, it's not
>> only possible to enforce ARPs, the balance (proxy) IdP negotiation
>> power i far stronger. Feel free to have a look at http://wayf.dk/wayfweb/about_attributes.html
>> >
>> >> With openID there is a more consistent pattern of the IdP asking
>> for consent, this is more of a deployment choice by the IdP rather
>> than something inherent in the protocol.
>> >>
>> >> None of the protocols support the sort of notice that the
>> privacy community is asking for. The IdP has no in-band way to
>> know what the SP is collecting the attribute for or what the
>> consequence of not providing it is.
>> >
>> > This is at the heart of the problem: SPs should only recieve
>> attributes which balance the purpose of the service delivered. Two
>> (legal) principles come into play: proportionality and minimal
>> disclosure.
>> >
>> >> The closest they come is a devision between required attributes
>> and optional attributes.
>> >> Though interpritations of those can vary as well.
>> >>
>> >> Some IdP ignore optional attributes and never return them.
>> Leading RP/SP to make them all required.
>> >>
>> >> Attributes are an area not covered in the IAF or in FICAM to any
>> extent. The existing frameworks concentrate almost exclusively on
>> the identifier. As the identifier may be the persons proofed name
>> and address in some systems, that is normally the extent of it.
>> >>
>> >> John B
>> >
>> > Have a good weekend,
>> >
>> > David SImonsen
>> >
>> >
>> >
>> > David Simonsen
>> > Executive manager
>> > Phone: +45 31216152
>> >
>> > H. C. Andersens Boulevard 2
>> > DK-1553 København V
>> >
>> >> On 2011-03-11, at 10:24 AM, Mark Lizar wrote:
>> >>
>> >>>
>> >>> Hello All,
>> >>>
>> >>> Last October at the Kantara Face 2 Face I presented on the
>> efforts of P3 and our move towards developing a privacy framework.
>> At the time of the presentation we discussed liaising with
>> different work groups inside Kantara.
>> >>>
>> >>> Since this time I have been thinking about what kind of liaison
>> would be useful and productive. As I am currently working on
>> summary of the Consent and Notice Privacy principles for the PF-SG
>> (next week) and considering the great thread that has revolved
>> around discussing terms, I thought I would maybe combine my
>> deliverable with a bit of information gathering.
>> >>>
>> >>> John, is it possible to get more information (references) on
>> the use of Notice and Consent in SAML and SSO? (If there is any in
>> reference to the data subject or Principal?)
>> >>>
>> >>> Also, could I ask someone (like Ben Wilson) to provide a
>> summary of Consent and Notice in IAF? e.g. References to the
>> differences in notice or consent at varying levels of Insurance?
>> >>>
>> >>> I would be grateful for this type of help and I would like to
>> include this in the analysis I will be working on next week. (if
>> possible)
>> >>>
>> >>> Best Regards,
>> >>>
>> >>> Mark Lizar
>> >>> P3 Secretary
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> WG-IDAssurance mailing list
>> WG-IDAssurance at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
>>
>>
>> _______________________________________________
>> WG-IDAssurance mailing list
>> WG-IDAssurance at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
>
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAssurance at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110311/2b4aef1f/attachment-0001.html
More information about the WG-IDAssurance
mailing list