[OpenID] http and https...again

[Peter Williams]

If two RPs each provisioned by a given OP each signal the ?arg=value to each other, then the value can act as half of the (unique, per flow) entropy. The two RPs can then generate keying material, on the basis that the OP is the ttp. In an n of m scheme for generating keying material from key partisions, n parties in multicast group can similarly generate group keying material.

The simple pairwise keying is cheap and nasty version of WS-SX - but it will essentially work. The two parties can then each perform the SSL KDF, and setup the security contexts, one for each pipe between the RPs.

IN this workd, openId auth (and its use of https, if any) is performing the same role as certs/kerboeros/GSSAPI do in a particular ciphersuite used in an SSL handshake.

This is quite a cute architecture. https (and its PKI) provides the control system over openid auth, which provides mutual authentication of RPs by proxy, who can derive unique pariwise keying material, which creates confidential/integral pipes between the RPs. Optionally, groupwise keying is shared between the OP and n RPs, for use in AX update. N of M math can require that a certain minimum number of RPs are party to the group.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Monday, September 08, 2008 2:28 PM
To: pnwtele at yahoo.com
Cc: general at openid.net
Subject: Re: [OpenID] http and https...again

I am very much in favor of OPs normalizing their identifiers.

But I daresay that if a user adds ?a=1 to a user identifier, he's not your average joe-blow user and knows exactly what he's doing.  Nothing wrong with that.  If the user wants to splinter his identity by adding query args, he should be free to do so, just as much as username/password doesn't prevent a user from creating to user accounts.
On Mon, Sep 8, 2008 at 1:49 PM, Joe Tele <pnwtele at yahoo.com<mailto:pnwtele at yahoo.com>> wrote:
Yes, it has nothing to do with fragments or recycling.  It has to do with inconsistencies with how OPs normalize (or not) their user's claimed ids from user supplied indentifiers.  Verisign does nothing.  These are types of things which could be argued as "features" or "bugs" but in my opinion could result in user base confusion (and RP confusion).


--- On Mon, 9/8/08, SitG Admin <sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>> wrote:

> From: SitG Admin <sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>>
> Subject: Re: [OpenID] http and https...again
> To: "Joe Tele" <pnwtele at yahoo.com<mailto:pnwtele at yahoo.com>>
> Cc: general at openid.net<mailto:general at openid.net>
> Date: Monday, September 8, 2008, 1:38 PM
> >http://openid.net/pipermail/general/2008-September/005426.html
>
> I don't know about Verizon, but your reference to a
> user typing in
> this extra information is a clue that this doesn't have
> to do with
> generation fragments (distinguishing between successive
> users with
> the same URI). I'm thinking it's either a user
> identification method
> (such as Sun offers to assert "This is one of our
> employees, but
> we're not saying exactly who.") that tells the OP
> (in this case,
> Verizon) who the user is claiming to be (facilitating the
> login flow)
> without revealing anything meaningful about the user's
> identity to
> the RP, or something weird with how Verizon is resolving
> claimed_id
> (if the URI is different enough to not qualify as the same
> user
> anymore, you'd think Verizon's OP would detect that
> and return an
> error that the user did not exist).
>
> Are you getting these "?a=1" variables appended
> by real users, or are
> they just showing up in tests? If the former, I'd
> assume it to be
> there for a reason; if the latter, I'd contact Verizon
> about it.
>
> -Shade



_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080908/8998641d/attachment-0002.htm>