[Wg-egov] FW: [security-services] SAML deployments that use consent step?

Wed Nov 11 21:05:55 EST 2009

OK, so I have an answer regards NZ's deployment of this.

NZ does a HTTP 'cludge' on the user consent-release of PII for its Identity Verification Service (IVS).  It does not (yet) use the SAML Consent attribute as do others.  IVS has put consent into the <AuthnResponse> to indicate that the user has (presumably) consented to having their identity details sent (seems like overkill, the fact that there's a successful response seems to indicate same but hey..).

But ....

This conversation going on over at the SSTC seems to be about the SP putting consent into an <AuthnRequest> (user consenting to federate).

It does not seem to be about an <AuthnResponse> use case as per the eGov Profile v1.5, DK, No, NZ etc.

Or maybe it's both and that not clear to me.

In the medium term I can foresee a time when deployments (and then the eGov Profile) will specify consent in an <AuthnRequest> (user consenting to federate).

Those of you who are aware of our GOAAMS (Govt Online Attribute Authority Meta System  ....whew!:-)) use case will see how such a session-based consent would really help the subsequent message flows as attributes are needed from various authorities within a federation and need to be passed to the service that the user wants access to.

Cheers

Colin

From: wg-egov-bounces at kantarainitiative.org [mailto:wg-egov-bounces at kantarainitiative.org] On Behalf Of Colin Wallis
Sent: Wednesday, 11 November 2009 6:05 a.m.
To: wg-egov at kantarainitiative.org
Subject: Re: [Wg-egov] FW: [security-services] SAML deployments that use consent step?

<<"User Interaction" mechanism (for asking the user, on an attribute-by-attribute bases) details of consent (this time only, always, never, always ask...) >>

..is basically the direction NZ is heading in.

We only have one service requiring it at present - the Identity Verification Service, where at some previous time when you renewed your passport, you ticked a box to allow the PII on your passport to be held electronically and released, with your consent, to other agencies that in future you wish to seek a service from, you don't have to front up with your passport or some other item, to go through the identity proofing process all over again that you did to get/renew  your passport..

Cheers
Colin

> From: futureidentity at fastmail.fm<mailto:futureidentity at fastmail.fm>
> To: spn at itst.dk<mailto:spn at itst.dk>; Colin.Wallis at dia.govt.nz<mailto:Colin.Wallis at dia.govt.nz>; kyle at drummondgroup.com<mailto:kyle at drummondgroup.com>; wg-egov at kantarainitiative.org<mailto:wg-egov at kantarainitiative.org>
> Date: Tue, 10 Nov 2009 11:23:52 +0000
> Subject: Re: [Wg-egov] FW: [security-services] SAML deployments that use consent step?
>
> I tend to agree with Søren Peter - consent in general is something worth
> doing more to include, rather than omit.
>
> Thinking back to the early days of Liberty (though Conor will remember
> more of this than I do), its specification of the "User Interaction"
> mechanism (for asking the user, on an attribute-by-attribute bases)
> details of consent (this time only, always, never, always ask...) was
> excellent but ahead of its time. I think since then (2002-2003...)
> awareness has been growing that attribute-level disclosure management is
> increasingly relevant.
>
> Wouldn't it be tragic if the general user culture finally swung round to
> attribute-level consent and we didn't have anything to offer?
>
> R
>
> On Tue, 10 Nov 2009 07:05 +0100, "Søren Peter Nielsen" <spn at itst.dk<mailto:spn at itst.dk>>
> wrote:
> > Denmark's OIOSAML profile requires the consent attribute included when
> > making an attributeQuery for personally sensitive data. However, I am
> > not sure though whether consent is being used in any Danish
> > deployments... Currently AttributeQuery is only being used in some scale
> > for requesting roles in a context where the requested data are not
> > considered personally sensitive.
> >
> > Consent in general is a thing we want to support better with
> > IT-technology - Several avenues are on the plate. Depending on where the
> > momentum comes use of the SAML consent feature may or may not swindle
> > away from the profile, but we do not have clarity about this yet.
> >
> > /Søren P
> > ________________________________________
> > From: wg-egov-bounces at kantarainitiative.org<mailto:wg-egov-bounces at kantarainitiative.org>
> > [wg-egov-bounces at kantarainitiative.org] On Behalf Of Colin Wallis
> > [Colin.Wallis at dia.govt.nz]
> > Sent: Tuesday, November 10, 2009 3:25 AM
> > To: 'Kyle Meadors'; wg-egov at kantarainitiative.org<mailto:wg-egov at kantarainitiative.org>
> > Subject: Re: [Wg-egov] FW: [security-services] SAML deployments that use
> > consent step?
> >
> > Yep, I'm following it as best I can with an already overflowing
> > mailbox..:-)
> >
> > I'm pretty sure NZ uses the Consent attribute in our deployment. We
> > absolutely deploy consent, so I just need to double check that it does it
> > using the Consent attribute.
> >
> > I think Denmark does too.
> >
> > Cheers
> > Colin
> >
> > -----Original Message-----
> > From: wg-egov-bounces at kantarainitiative.org<mailto:wg-egov-bounces at kantarainitiative.org>
> > [mailto:wg-egov-bounces at kantarainitiative.org]<mailto:[mailto:wg-egov-bounces at kantarainitiative.org]> On Behalf Of Kyle Meadors
> > Sent: Tuesday, 10 November 2009 1:17 p.m.
> > To: wg-egov at kantarainitiative.org<mailto:wg-egov at kantarainitiative.org>
> > Subject: [Wg-egov] FW: [security-services] SAML deployments that use
> > consent step?
> >
> > There is an interesting discussion occurring on the SSTC list on the
> > practical merits and use of the user consent feature within SAML. Below
> > is
> > just one of many emails in the discussion
> > (http://lists.oasis-open.org/archives/security-services/200911/threads.html)
> > .
> >
> > The eGov profile has the Consent attribute being a MUST support within
> > IdP
> > AuthnResponse and we tested in the previous SAML IOP test event. However,
> > several have commented that they are not aware of its use within the
> > real-world.
> >
> > I think it is always a good for authors of profiles and test plans to
> > periodically question the validity of their requirements. So just asking,
> > is
> > it worth keeping this in our profile and also testing it within the KI
> > program?
> >
> > Kyle Meadors
> > DGI
> >
> > * * * * * * * * * * * * * * * * * * * * * * * *
> > CONFIDENTIALITY DISCLAIMER
> > This email, including attachments, is confidential and proprietary. It
> > constitutes exclusive communication solely to the addressee. Any entity
> > other than the intended addressee is prohibited from use of this
> > communication for any purpose. This email, including attachments, may not
> > be
> > distributed, whole or in part.
> > * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > -----Original Message-----
> > From: Cahill, Conor P [mailto:conor.p.cahill at intel.com]<mailto:[mailto:conor.p.cahill at intel.com]>
> > Sent: Monday, November 09, 2009 4:12 PM
> > To: Josh Howlett; Scott Cantor
> > Cc: 'Paul Madsen'; 'oasis sstc'
> > Subject: RE: [security-services] SAML deployments that use consent step?
> >
> > The consent flag came about when some members of the Public Policy EG
> > within
> > Liberty thought that it was useful to have a positive indicator from the
> > RP that it had, in fact, gathered consent to the user before attempting
> > the
> > federation. I argued against that saying that the existence of the
> > request
> > was good enough proof that the RP believed it was acting under user
> > consent.
> > This was another one that I lost (amongst many).
> >
> > The basic model around an RP obtaining consent from the user is where the
> > IdP has a relationship with the RP such that it trusts the RP to obtain
> > consent from the user for a federation and/or SSO event before submitting
> > the request. In such cases, allowing the RP to indicate that they have
> > obtained consent can relieve the IdP from having to perform its own check
> > with the user for consent to establish a new relationship with the RP.
> >
> > This level of relationship is usually based upon legally binding
> > agreements
> > that govern the behavior of the RP and, to some extent, treat the RP as
> > an
> > extension of the IdP for the purpose of obtaining consent.
> >
> > In other cases, where you don't have that level of trust of the RP, the
> > IdP will perform its own consent checks with the user (or will operate
> > under
> > some other out-of-band mechanism re: consent -- this is typically what is
> > understood in the business-to-employee environment where the employee is
> > assumed to have already given consent to the employer to federate the
> > users
> > identity amongst the systems running the organization and individual
> > consents from the user aren't necessary).
> >
> > Conor
> >
> > -----Original Message-----
> > From: Josh Howlett [mailto:josh.howlett at gmail.com]<mailto:[mailto:josh.howlett at gmail.com]>
> > Sent: Monday, November 09, 2009 5:00 PM
> > To: Scott Cantor
> > Cc: Josh Howlett; 'Paul Madsen'; 'oasis sstc'
> > Subject: Re: [security-services] SAML deployments that use consent step?
> >
> > On 9 Nov 2009, at 21:41, Scott Cantor wrote:
> > > Josh Howlett wrote on 2009-11-09:
> > >> While we're on the subject, I've always been a bit puzzled about the
> > >> use-cases for the consent identifiers; in particular, why an RP might
> > >> care whether consent has been given or not.
> > >
> > > They're for auditing, essentially. You get a signed document
> > > indicating
> > > something about consent so you can point the finger later.
> >
> > Ok. In the EU consent is irrelevant as far as an RP is concerned, as
> > the IdP is liable by default when TSHTF. I can't think of a scenario
> > where an RP would need to retrospectively demonstrate consent.
> >
> > > The more bizarre use case to me was always why an IdP would care about
> > > consent
> >
> > You'll need to expand on that for me. When does an IdP receive a
> > consent identifier?
> >
> > josh.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> > _______________________________________________
> > Wg-egov mailing list
> > Wg-egov at kantarainitiative.org<mailto:Wg-egov at kantarainitiative.org>
> > http://kantarainitiative.org/mailman/listinfo/wg-egov
> > ====
> > CAUTION: This email message and any attachments contain information that
> > may be confidential and may be LEGALLY PRIVILEGED. If you are not the
> > intended recipient, any use, disclosure or copying of this message or
> > attachments is strictly prohibited. If you have received this email
> > message in error please notify us immediately and erase all copies of the
> > message and attachments. Thank you.
> > ====
> > _Snip>

====
CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
====
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-egov/attachments/20091112/eaec5c39/attachment-0001.html 