[OpenID] OpenID SREG best practice question

[Deron Meranda]

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 !!

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