[OpenID] OpenID SREG best practice question

[Breno de Medeiros]

On Wed, Nov 12, 2008 at 11:24 AM, Deron Meranda <deron.meranda at gmail.com> wrote:
> On Wed, Nov 12, 2008 at 1: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'm assuming this is partly because Google will only ever send an AX
> attribute if is is listed as "required" by the RP.  And, although the
> OpenID spec is not very clear on the matter, it would seem that the
> OP should only either send required attributes or reject the entire
> request (hence the user shouldn't be given a selective choice).
>
> If Google on the other hand didn't just ignore the "if_available"
> requested attributes; then it would seem that the user should be
> given a choice to send or not on an attribute by attribute basis
> for those that are not required, without necessarily having to cancel
> the entire transaction.
>
>
>> 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).
>
> Being able to choose different values is quite different than being
> able to choose whether to return an attribute or not.  I think it
> depends on the OP which attributes they would allow you to
> customize and which they won't.  For email providers like Google
> it's probably reasonable that they don't let you choose arbitrary
> email addresses.  But certainly, if they ever support timezone, they
> should let the user pick that one.
>
>
>> 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",
>
> Yes, I think all OPs should always allow the end user to see exactly
> what data is being sent to the RP; whether that be via SReg or AX.
>
> I find it strange that Google will show you the AX/email attribute
> it is sending; but won't show you the claimed_id !!

By default, Google OP sends an opaque, per-RP identifier and there is
no benefit in showing these to users. When we support correlatable
identifiers, we will show these to the user.

>
> One of the better UIs I've seen is Verisign's.  It goes quite far in
> that (they only support SReg), they not only show you every field
> and its value; they also keep a log of all transactions with
> attribute values which the user can review later.
>
> Verisign also has a nice way to let you chose which values to
> send back for each attribute.  Not only can you customize each
> value for each request, you can also build a set of attribute
> "personas"; and choose which sets to send back to which RP
> to reduce the click-count.  That's pretty nice.
>
>
>> 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.
>
> Yes, directed identity does reduce the chances that the RP
> may know it already has the data and thus doesn't need to
> ask for it again.
>
> But also keep in mind that if you're going to start designing
> parties that base their decisions on what to do depending
> on what historic transactions occurred, you're introducing
> a lot of state keeping.  Also what happens when one of the
> parties (RP or OP) decides its state is too old and has aged
> it off.  If the RP has purged its data from a week ago, but
> the OP still remembers it already sent the data and thus
> decides it won't send it again; then the RP won't get the
> data.
>
> I think that if the RP asks for the data, the OP should always
> send it (unless the end user overrides this).
>
> --
> Deron Meranda
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)