Peter,<br><br>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??<br>
<br>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.<br>
<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Fri, May 8, 2009 at 4:41 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1 attribute service<br>
<br>
Said that way, this seems to describe a "confirmed attribute" service.<br>
<br>
It asks: Is there an attribute authority will to assert the validity of some or other attribute?<br>
<br>
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.<br>
<br>
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.<br>
<br>
2 DOA semantics<br>
<br>
Now, if I argue against myself, perhaps Im wrong! (whats new!)<br>
<br>
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.<br>
<br>
3 PS<br>
<br>
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.<br>
<br>
________________________________________<br>
From: Andrew Arnott [<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>]<br>
Sent: Thursday, May 07, 2009 2:41 PM<br>
To: Breno de Medeiros<br>
Cc: Peter Williams; Johannes Ernst; general<br>
Subject: Re: Identity-less OpenID<br>
<div><div></div><div class="h5"><br>
I don't think the two parties have to come to any agreement for it to<br>
be useful. Take the Google OP for example. An RP could skip the email<br>
verification step if a user enters a gmail address by sending an AX<br>
request to Google. This hypothetical RP doesn't want google's claimed<br>
identifier for this user--just the email. This RP trusts Google and if<br>
Google sends the same email back in the AX response then the email is<br>
verified.<br>
<br>
If you want to verify organization membership then yes some kind of AX<br>
attribute will have to have an agreed use between the two parties to<br>
be very useful.<br>
<br>
On Thursday, May 7, 2009, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
> Andrew,<br>
><br>
> I happen to agree that the feature is potentially useful. However, it<br>
> requires prior agreement between the two parties about what a "group"<br>
> is. Do you mean simply that the user can authenticate herself to the<br>
> OP?<br>
><br>
> On Thu, May 7, 2009 at 9:33 AM, Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>> wrote:<br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> ________________________________<br>
>> From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>] On Behalf Of Johannes Ernst [jernst+<a href="http://openid.net" target="_blank">openid.net</a>@<a href="http://netmesh.us" target="_blank">netmesh.us</a>]<br>
>> Sent: Thursday, May 07, 2009 8:40 AM<br>
>> To: Andrew Arnott<br>
>> Cc: general<br>
>> Subject: Re: [OpenID] Identity-less OpenID<br>
>><br>
>><br>
>> On May 6, 2009, at 21:22, Andrew Arnott wrote:<br>
>><br>
>> 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, <a href="http://myopenid.com" target="_blank">myopenid.com</a><<a href="http://myopenid.com" target="_blank">http://myopenid.com</a>>: no, Yahoo.com: no, <a href="http://myvidoop.com" target="_blank">myvidoop.com</a><<a href="http://myvidoop.com" target="_blank">http://myvidoop.com</a>>: no. I'm out of OPs that I'd have guessed had any chance of supporting it. (Actually, I guess <a href="http://myvidoop.com" target="_blank">myvidoop.com</a><<a href="http://myvidoop.com" target="_blank">http://myvidoop.com</a>> 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."<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>><br>
>><br>
>> 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.<br>
>><br>
>> In fact there are many times perhaps when the RP doesn't care h> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
> +1 (650) 214-1007 desk<br>
> +1 (408) 212-0135 (Grand Central)<br>
> MTV-41-3 : 383-A<br>
> PST (GMT-8) / PDT(GMT-7)<br>
><br>
<br>
--<br>
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the<br>
death your right to say it." - Voltaire<br>
</div></div></blockquote></div><br>