[OpenID] Demo Travel/ retailshop

[Peter Williams]

so out of interest, when designing/building your RP library for .NET, how did you plan for the compromise of the "spoofing secret(s)" from the implementation's key/handle store? Do you leverage other .NET mechanisms for storing secrets?

For the native openid handshake, I decided a long time ago to persist association secrets with a binding to an https endpoint (aka a valid cert chain's hash sequence in the RP's security MIB + HTTPS url path). When handling an assertion, I considered it appropriate to check that the originator's transport endpoint is consistent with the endpoint data persisted with the handle. That is: its not enough for the assertion maker (normally an OP) to merely show knowledge of the secret. I imposed this "SSL handshake assurance" rule to address the nature of openid's native data origin authentication mechanism choice - a specifically duplex, symmetric secret. I essentially reimposed the [missing] properties of cert-based asymmetric key distribution and key derivation by read/write channel by imposing that handling rule.

If we move openid into the PCI audit space, which typically includes a measure of analysis of the strength of and assurance of the security protocols actually in use in the application context, we have to be concerned with the compromise handling properties of the protocol (implementation). Traditionally, a lot of the design of typical upper layer security services is concerned with preparations for the recovery phase of security incidents - not only normal phase handling procedures. If we are really allowed to use _external_ association procedures to support openid assertion authentication -- in lieu of the native procedures -- then each will have particular properties concerning the lifecycle and distribution of (derived) authentication secrets.

________________________________
From: Andrew Arnott [andrewarnott at gmail.com]
Sent: Sunday, April 26, 2009 4:55 PM
To: Peter Williams
Cc: SitG Admin; general at openid.net
Subject: Re: [OpenID] Demo Travel/ retailshop

Sharing your association secret from one RP to another site does not bestow any right other than "now able to forge identity assertions on behalf of the OP and fool the RP".  It makes no difference to the OP what assoc_handle an RP uses as far as determining privileges to access certain attributes.

--
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 Sun, Apr 26, 2009 at 4:24 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

or. im an rp and I give the association secret to my delegated rp-partner, who is now authorizd to ask for non-identity claims (given the restrictions in his RP XRDS and the nature of the association id). Lets recall, from plaxo, external association managers are now legitimate. no reason why one cannot consider oauth to be an "extenrnal" association manager, or a "complementary" association manager between RPs to faciliate rights delegation for non-identity requests/assertions.
________________________________________
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 SitG Admin [sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>]
Sent: Sunday, April 26, 2009 3:53 PM
To: Andrew Arnott
Cc: general at openid.net<mailto:general at openid.net>
Subject: Re: [OpenID] Demo Travel/ retailshop

>Effectively, the RP would be asking an OP "I already know who this
>user is, but I'd like to learn more about them."

Could it be used for "I don't care who this user is, I just want to
learn more about them."?

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