[OpenID] Identity-less OpenID

Thu May 21 03:42:37 UTC 2009

Sorry for the late reply.  Yes your #1 seems to say that you have an
attribute or claim based system that could provide access control.  I
wouldn't use it for identity, but attribute claims could be asserted in this
way if the RP trusted the OP.

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

On Fri, May 8, 2009 at 2:12 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

> ok - your saying that 2 was wrong. That's fine. I was arguing with myself
> in 2, trying to see if there is something subtle in openid's crypto for a
> identityless transaction following a identity transaction. I declared my own
> contradiction, clearly. Perhaps there _is_ nothing subtle.
>
> What we know is that the spec says little or nothing...about the topic, the
> semantics, the use cases, the conformance. All we know is it exists,
> occupies about 10 words in the spec, is a relic of something ex-sxip folks
> were trying to do with "attributes", nobody does it, and attribute-centric
> AX doesn't use it (since AX responders exist without using the mechanism).
>
> what about 1? is that a fair summary? It seems to characterize your
> suggested use case for the mechanism, and analyze the semantics. is it fair
> to say that the semantics are identical to using ldaps to recover an
> attribute, from an directory agent that "vouch for" the attribute values it
> distributes?
>
> In general, is 1 the limit of the applicability of identityless
> transactions using openid auth protocol?
>
> or is 1 just a particular use case of the more general mechanism?
>
> if its general, a library would expose the core methods to custom extension
> writers so they can then run with additional use cases.
>
> ________________________________
> From: Andrew Arnott [andrewarnott at gmail.com]
> Sent: Friday, May 08, 2009 7:57 AM
> To: Peter Williams
> Cc: Breno de Medeiros; Johannes Ernst; general
> Subject: Re: Identity-less OpenID
>
> 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
> <mailto: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<mailto: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<mailto:
> 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
> <mailto: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<mailto:general-bounces at openid.net> [
> general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf
> Of Johannes Ernst [jernst+openid.net<http://openid.net>@netmesh.us<
> http://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><http://myopenid.com>: no,
> Yahoo.com: no, myvidoop.com<http://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><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/20090520/8907a6ac/attachment.htm>