[OpenID] Identity-less OpenID

[Peter Williams]

That workflow (identiless follows identity-checking) had always been my assumption about the role of the mechanism. But it was just an assumption, since te spec says little. Of course , it looks just like 1. an rp receives a saml assertion, after which 2. the rp does an attributequery - as was done commonly in the saml1 era of websso.

Then, going beyond saml, if the rp communicates yet another extension in a second identiless transaction (one that uploads from rp the users cert, to be placed in the op-hosted discovery record, say) that too would be a "followup" identiyless transaction. That cert extenson is just an example, simply trying to have nothing to do with ax - to help determine if intended semantics of identiyless exchanges are or are not limited to ax-related dialogs.

-----Original Message-----
From: George Fletcher <gffletch at aol.com>
Sent: Friday, May 08, 2009 8:22 AM
To: Breno de Medeiros <breno at google.com>
Cc: general <general at openid.net>
Subject: Re: [OpenID] Identity-less OpenID

I have a slightly different flow I've been contemplating which might
require this AX only "feature".

The issue is that with "directed identity" an RP has to ask for AX (or
SREG) data on every authentication request even if the RP already has
the data. Now there are times where "asking every time" makes sense
(i.e. the RP never stores the data persistently). However, having the
user's data (sometimes PII) flow across the wire on every authentication
and with that flow being via the browser, it seems like we are
increasing the risk of PII "leakage" just by the fact that it's present
in every transaction.

So what I've been thinking about, is just doing a plain "directed
identity" transaction, and if the resulting identifier is not known to
the RP, then starting an AX transaction to request the additional
attributes. This does have performance implications due to the
additional redirects required to complete the flow. However, the actual
UX wouldn't be that different than what many see today.

    The first screen the user sees is the authentication screen. The
    user enters their credentials and are returned to the RP. The RP
    then determines whether attributes are needed and if so redirects to
    the OP with the AX request for the needed attributes. The user then
    sees the consent page to release the attributes. The same as it
    works today.

I suppose that this second request could still be an authentication
request with a mode of "check_setup" and since the user has just
authenticated the OP would skip the authentication step. However, since
the user is already authenticated, it would be nice for this to just be
an AX request.

Thoughts?

Thanks,
George


Breno de Medeiros wrote:
> Our recently introduced new UI remove reference to 'sign in' when
> other attributes are requested (e.g., email). We did it on purpose to
> make it more general in application.
>
> You can now achieve the same result by sending a traditional OpenID +
> AX request to the Google OP and saving the email address.
>
> On Thu, May 7, 2009 at 2:41 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
>
>> I don't think the two parties have to come to any agreement for it to
>> be useful. Take the Google OP for example. An RP could skip the email
>> verification step if a user enters a gmail address by sending an AX
>> request to Google. This hypothetical RP doesn't want google's claimed
>> identifier for this user--just the email. This RP trusts Google and if
>> Google sends the same email back in the AX response then the email is
>> verified.
>>
>
>
>
>
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general