[OpenID] Identity-less OpenID

Fri May 8 14:57:48 UTC 2009

Peter,

I'm sorry, and I think I've said this before, but you're tending to talk
about really deep encryption stuff when it really has nothing to do with
OpenID, IMO.  Why would you be maintaining state of a stateful encryption
algorithm at such a high level as part of the query string in an OpenID
request??

Besides, you keep talking about an association handle being bound to a
certain OpenID, and that's way way off the spec.  An association handle
represents a shared secret between an RP and an OP, and should be reusable
by many authentication requests for many users.  It sounds like your whole
premise is around the association being bound to the first user that uses
it.  That sounds like a contradiction.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire

On Fri, May 8, 2009 at 4:41 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

> 1 attribute service
>
> Said that way, this seems to describe a "confirmed attribute" service.
>
> It asks: Is there an attribute authority will to assert the validity of
> some or other attribute?
>
> If the RP happens to treat that attribute and its validity assertion upon
> receipt as an identity claim, then one has a simple assertion protocol.
>
> Of course, that identity protocol has none of the features of openid auth
> state machine and security controls: control, delegation, consent, realms,
> portability, etc.  One might as well being using ldaps, where the ssl bearer
> give the attribute retrieval all that openid seems to be providing the
> attribute retrieval: a data origin authentication service.
>
> 2 DOA semantics
>
> Now, if I argue against myself, perhaps Im wrong! (whats new!)
>
> Perhaps one can claim that since a given association handle being used
> ...this establishes that the RP invoking the identityless transaction is
> acting in some sense as a delegate of the end user - when using the handle
> for data origin authentication of an extension blob - since that association
> handle is bound up with a particular user's openid.
>
> 3 PS
>
> I really wish openid has a formal security model, rather than using
> minimalist spec techniques. The lack of a formal model going to hold openid
> back, in many adoption circles.
>
> ________________________________________
> From: Andrew Arnott [andrewarnott at gmail.com]
> Sent: Thursday, May 07, 2009 2:41 PM
> To: Breno de Medeiros
> Cc: Peter Williams; Johannes Ernst; general
> Subject: Re: Identity-less OpenID
>
> 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.
>
> If you want to verify organization membership then yes some kind of AX
> attribute will have to have an agreed use between the two parties to
> be very useful.
>
> On Thursday, May 7, 2009, Breno de Medeiros <breno at google.com> wrote:
> > Andrew,
> >
> > I happen to agree that the feature is potentially useful. However, it
> > requires prior agreement between the two parties about what a "group"
> > is. Do you mean simply that the user can authenticate herself to the
> > OP?
> >
> > On Thu, May 7, 2009 at 9:33 AM, Peter Williams <pwilliams at rapattoni.com>
> wrote:
> >> i have to admit, I know nothing about Sxip protocols or directions. Ive
> only ever followed standards. ONly through standards does one address scale
> and fair competition between vendors.
> >>
> >> But, the feature was always intriguing. It implied, along with
> delegation, that openid protocol entities operating in a more advanced
> application context could be stateful over even multiple transactions.
> >>
> >> In the WS-SX world, before a soap xml document gets send over a binding,
> multiple transactions are performed by the communication bearer - to prepare
> a secure channel for the message exchange pattern. I always imagined the
> openid identityless feature facilitating what WS-SX facilitates, performing
> multiple communication-transactions - borne in openid extensions - that
> negotiate the requirement (crypto, timeliness, addressing) & policies of the
> endpoints. This is all in preparation, of course, for the MEP transactions
> the user is actually confirming with an identity transaction.
> >>
> >> In formal assurance language, the openid identitiy transaction would be
> known the identity protocol, which must complete to establish the security
> association.. identity-less transactions would be used when
> creating/maintaining/re-building the security association. Once there is an
> association or re-association that satisfied policies, then there can then
> be the actual exchange of information objects.
> >>
> >> ________________________________
> >> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf
> Of Johannes Ernst [jernst+openid.net at netmesh.us]
> >> Sent: Thursday, May 07, 2009 8:40 AM
> >> To: Andrew Arnott
> >> Cc: general
> >> Subject: Re: [OpenID] Identity-less OpenID
> >>
> >>
> >> On May 6, 2009, at 21:22, Andrew Arnott wrote:
> >>
> >> The OpenID 2.0 spec allows for checkid_* messages to omit
> openid.identity and openid.claimed_id in order to send a message whose
> useful is entirely in the extensions it carries.  For a long time I thought
> "what's the point of that??" but I finally found a use case.  So I'm adding
> built-in support for it into DotNetOpenAuth both at the RP and OP sides.
>  Now that I've done it, I'm checking various OPs to see if they support it.
>  Google: no, myopenid.com<http://myopenid.com>: no, Yahoo.com: no,
> myvidoop.com<http://myvidoop.com>: no.  I'm out of OPs that I'd have
> guessed had any chance of supporting it. (Actually, I guess myvidoop.com<
> http://myvidoop.com> didn't have a chance since they only do a strange
> mixture of OpenID 1.1 with some 2.0 features support).  My favorite part of
> this is that every OP says there's something wrong with the request, instead
> of "this feature isn't supported."
> >>
> >> Does anyone know of an OP that actually supports this feature?  (or an
> RP that uses it?)  I'm puzzled that such a feature was included in the spec
> without anyone driving for its support.
> >>
> >> I believe this was one of Sxip's contributions that was closer to the
> roots of the original Sxip protocols that weren't driven by a unique
> identifier / URL.
> >>
> >>
> >>
> >> In case you're interested in the scenario in which this is useful, here
> it is:  Remember past threads where I've advocated against an organization
> becoming an OP just so RPs can force users to log in with that OP to verify
> some membership in the organization?    The alternative that I had proposed
> was for that org to set up an OAuth SP. While that idea is still valid, it
> might be the only reason for that org and an RP to add OAuth support, which
> may not be trivial.  If, on the other hand, the RP sent an identity-less
> OpenID request to the org's OP, with an "organization member check"
> extension request, then the OP could issue a positive assertion that carries
> no identity, but can assert that yes, the user is in fact a member of the
> org.  Of course the OP would still have to authenticate the user somehow,
> but the RP and OP would not have to agree on an Identifier to use for
> referring to the person.
> >>
> >> In fact there are many times perhaps when the RP doesn't care h>
> 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)
> >
>
> --
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the
> death your right to say it." - Voltaire
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090508/fcf432ef/attachment.htm>