[OpenID] OpenID SREG best practice question

[Ben Laurie]

On Wed, Nov 12, 2008 at 6:57 PM, George Fletcher <gffletch at aol.com> wrote:
> So when I as interacting with the Google implementation, one feature
> that I was looking for was the ability to continue the OpenID
> authentication without sending my gmail address. Since this option
> wasn't available, my only choice was to cancel the authentication. I
> would have preferred to continue to "login" to the RP but be able to
> specify a different email address at the RP (if the RP needs an email
> address).

Yeah, I wanted to offer this option, too, but we decided to keep it
simple for now.

I should note that if the email address is actually optional, then the
RP could give you the option to not ask for it. But I suspect that
this would be clunkier than allowing you to choose when you agree to
be authenticated.

Clearly as (if?) more attributes get added into the mix more thought
will have to go into this aspect.

>
> Otherwise, I think I'm ok with the concept of "if showing UI to the user
> for authentication, also show the data that will be sent as part of
> SREG/AX", or "if not showing UI (e.g. check_immediate will succeed) and
> the user has auto-approved, then don't send the data".
>
> If I understand correctly, that's basically the rule set.
>
> I like the idea of tracking when the data changes and doing something
> special then. I'd love to see RPs only ask for SREG data when they need
> it. However, this is increasingly difficult with directed identity as
> the RP doesn't know who the user is until after authentication.
>
> Thanks,
> George
>
> Breno de Medeiros wrote:
>> On Wed, Nov 12, 2008 at 8:20 AM, George Fletcher <gffletch at aol.com> wrote:
>>
>>> Hi,
>>>
>>> I've been re-reading the SREG spec and I'm unsure as to the best/correct
>>> behavior in the case that an RP asks for SREG data that the user has
>>> already provided/consented to in the past. I see at least 3 options..
>>>
>>> 1. Should the OP (which knows the user gave consent for the requested
>>> fields) just not return them (on the principal that the fewer times
>>> "PII" flows over the wire the more the user's privacy is protected)?
>>>
>>
>> In the Google implementation of AX for email, we send the email
>> everytime that the user is prompted. So, if the user selects
>> auto-approval and the authentication is transparent to the user, the
>> email is not sent. If the value of the email changes from the value
>> last sent, the user is prompted (even if he has opted for
>> auto-approval) and the new value is sent (if user consents).
>>
>> We this is a good balance between disclosing "sensitive" attributes
>> only with user consent, while providing the ability to keep the RP
>> up-to-date with the user email, and also support transparent
>> authentication.  If we expand support for other attributes that are
>> less sensitive than email we may adopt a different balance for those.
>>
>>
>>
>>> 2. Should the OP silently (meaning no UI message relating to SREG)
>>> return the requested data if the user has given consent in the past (on
>>> the principle that the user gave consent in the past so this data can be
>>> returned without asking the user again).
>>>
>>> 3. Should the OP always ask the user what to do but defaulting the data
>>> that is sent based on the previous consent? This adds a UI page to every
>>> OpenID authentication that requests SREG data.
>>>
>>> Has anyone else worked through these issues? Any best practices to follow?
>>>
>>> Thanks,
>>> George
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>>
>>
>>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>