shibboleth-dev - Re: [Shib-Dev] [IdPv3] Consent Engine Work
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To:
- Cc:
- Subject: Re: [Shib-Dev] [IdPv3] Consent Engine Work
- Date: Mon, 15 Nov 2010 12:10:39 -0600
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AqokiAjW+dnRTG1mOOy+wU7GQNeMD1jOOqIdVCoDvqvgj/KUZiqSxola9nrC3PJ9fn P5pWu0Q7ZQcG06T32a5GZnxY7EqLaCoiFuaviaHQmQQYAdiIAcPp7Gw4dHM4x3elJ2cb 1onVJ+2tj9aYATKgesFbnmaYlnYJCmJRRv2RU=
On Mon, Nov 15, 2010 at 11:25 AM, Halm Reusser
<>
wrote:
>
> If a user checks such a
> box, it should mean "I accept that these attributes, which are listed
> above, including exact those values" might be released to every other
> service provider I access in the future". This is straight and clean.
As long as there's a configuration option to disable this feature,
that's fine. (I'd be inclined to disable this "feature.")
> This implies, the user has to confirm the attribute release again, if
> he access an already visited or new service provider and
>
> ... attributes, on which he did not give "global consent",
> will be released.
>
> ... attributes, on which he did give "global consent",
> but the values have changed will be released.
Are you suggesting that global consent be applied on an
attribute-by-attribute basis? That doesn't seem like the correct
granularity. Have you looked at the Cardspace metaphor recently? (I
haven't, but I wonder if it applies here.)
Just my 2 cents worth,
Tom
- Re: [Shib-Dev] [IdPv3] Consent Engine Work, Halm Reusser, 11/15/2010
- RE: [Shib-Dev] [IdPv3] Consent Engine Work, Peter Williams, 11/15/2010
- Re: [Shib-Dev] [IdPv3] Consent Engine Work, Tom Scavo, 11/15/2010
- Re: [Shib-Dev] [IdPv3] Consent Engine Work, Chad La Joie, 11/15/2010
- Re: [Shib-Dev] [IdPv3] Consent Engine Work, Halm Reusser, 11/16/2010
Archive powered by MHonArc 2.6.16.