[OpenID] OpenID SREG best practice question

[Peter Williams]

One thing I experimented  with, to keep the UCI (sp-centric) faith, was put the URL of the users own AX endpoint in one of the sreg fields to be delivered by a major consumer OP - like a Google. (I actually used myopenid for this, in reality)

Rather than get my attributes from google OP (restricted by **me** to doing enrollment/auth concerning my delegated identity), an RP builds an second association (identity/openid req fields blank) with my AX endpoint, and does AX retrieval.

Once I have Nat's terms acceptance protocol as an extension that rides on that association/session, the RP (not the Google IDP) will be bound to my license on how my copyrighted attributes MUST be handled (subject to the license).I don't want Google doing that: I don't trust them enough, as a consumer (im sure they will be putting my personal data into their search businessor some govts' consumer-wide correlation databases).

OpenID framework seems perfectly capable of splitting auth authority from attribute authority. Under UCI doctrine,  I have no problem with a high assurance auth service like Google running a discovery/locator service for my OP's AX endpoint URL.

Im thinking of putting an sha hash of my AX endpoint's self-signed root cert in that sreg/URL that google distribute, too. In this way, google is bootstrapping my own trust infrastructure for me, on a huge scale.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of George Fletcher
Sent: Wednesday, November 12, 2008 10:58 AM
To: OpenID General
Subject: Re: [OpenID] OpenID SREG best practice question

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).

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