[OpenID] Verisign Announces Free OpenID Digital Lockbox

Sat Feb 21 19:21:48 UTC 2009

Thinking about this more, VeriSign is going with the right security architecture (for a de-centralized, crypto-driven web capable of enforcing local privacy policies).We can see what is right with it, in architectural terms, by comparison with other conceptions of the world of "controlled attribute release and repurposing".

In the Shib2/SAML2 conception of the world of websso, the OP=IDP is all powerful; second only to the masterful and typically highly-nationalistic "federation" that  SHOULD govern who MAY talk to whom(*). Though the underlying SAML protocols support RP-centric (aka SAML SP-centred) federations just as well as they do support idp-centric federations (particularly when exploiting the SAML websso "affiliation" model), they are not being widely promoted these days in websso circles.

In OpenID and OAUTH, the world is far more centered on the view of the user from the RP's perspective - a world in which OAUTH-SPs and OPs are merely supporting actors.

In contrast to the centralized vision, in the decentralized model the OpenID RP talks directly to users in a context of contractual privity, with or without the bootstrapping or intermediation of an OP or an OAUTH-SP. The several OPs and any SPs are mere "optional, redundant proxies" for the user, doing a bit of automated  assertion-minting or data-management work for the user from a web server (vs the user's always-on PC). When wanting an assertion, a user-authorized RP gets one from some or other OP, as negotiated with the user through discovery. When wanting delegation-assertions, RPs get them  from  some other openid/OAUTH hybrid OP. When seeking privileges on a data store, a given RP now leverages is delegation-assertion grant to get those to which it is entitled ...from the particular OAUTH-SP.

Now in this rp-centric world, a particular OP that happens to operated a trusted crypto-vault service could be supporting several "affiliations" of RPs with which the user interacts- where any one affiliation is a particular subset of those OAUTH consumers who have each been granted a suitable delegation-assertion that the OAUTH handshake will require - to get either write or read privileges on the vault-managed data-records pertaining to that affiliation.

If we take a  music player-licensing/distribution example, I CAN see a user logging on to a "hybrid-class" myopenid OP (say), using live.com's non-hybrid OP or cardspace STS  as an authenticator fro the myopenid OP session. The per-user vault service of myopenid may now support 2 affiliations say - each a distinct OAUTH-SP, formally. Only RP-affiliation members can gain privileged access to the associated crypto-compartment within the vault ( in which Live OP as authenticator is not an affiliation member, though myopenid's hybrid OP is - as vault operator). Should the user consensually release a myopenid name assertion to a particular OpenID RP store distributing music licenses, the hybrid openid/oauth myopenid could now be creating a suitable delegation-assertion. This would  allow the music-RP to write records (music file) to the crypto compartment of the user's vault, as fronted by the OAUTH-SP protocol engine that is co-resident with the OP's openid engine. If contributing keying material to the security of the records stored in this depository, the writing/owning RP could be crypto-limiting (on an end-end basis) release of plaintext version of the record - limiting the unwrapping privilege to only those members of the particular RP affiliation associated  with the particular vault compartment to which their  delegation-assertion grant pertains (
.
Multi stage DH has all the crypto one needs for these types of point-to-multipoint topology schemes, where crypto is the writer-to-reader access control primitive. (Lookup "KEA" in IETF documents, for more info). In VeriSign's case, one can see the PIP hardware token (an application of OATH OTPs rather than securid or s/key OTPs) itself being part of the crypto-enforcement. In that world, the authenticator crypto-token is not only the means to confirm possession of authentication keying material pursuant to an OP logon, but its crypto-role is also participating in the user-centric release of records to particular rp-affiliations from the vault. This seems sensible given the relationship of some OTP algorithms with merkle-trees, as it limits the opportunity of OPs to go rogue on the user  in releasing attributes covert (with user consent, that is) - and thereby misuse authority.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Friday, February 20, 2009 11:33 PM
To: Chris Messina
Cc: OpenID List
Subject: Re: [OpenID] Verisign Announces Free OpenID Digital Lockbox

It may be conceived to be exactly what you say.

I didn't look at the OAUTH hybrid model element of the work  -- in which presumably the OP (cum authentication authority) acts as an OATH-SP storing not browser-uploaded photos but "just purchased stuff" now released to the openid auth authenticated subscriber (only) by the OAUTH-consumer=OpenID-Consumer.

Knowing VeriSign's business model for selling TTP services, the intent will _probably_ be to have the OP's trusted vault becomes the DRM enforcement point for the consumer site(s) selling "content"that can be "played" on other RP sites, etc. Finally a business model for OPs and social networks - the crypto-based shared-policy enforcer... for n RP sites! (aka the TTP business, a la AOL/MSN of the 1996 period!)

It is more interesting than the typical OATH world _because_ the OAUTH-Consumer is exploiting the security handshake to get for the OATH-RP write privileges (on the trusted vault) and get perhaps even participation in the keying of the RP-property deposited material within said vault., where the shared keying controls -- DRM-like - control data-release to other RPs.

Peter.

From: Chris Messina [mailto:chris.messina at gmail.com]
Sent: Friday, February 20, 2009 9:28 PM
To: Peter Williams
Cc: Andrew Arnott; OpenID List
Subject: Re: [OpenID] Verisign Announces Free OpenID Digital Lockbox

Personally, I'm interested in, at least in terms of how I read it, which may not be at all what this thing is, is a storage-in-the-cloud discovered off of your OpenID.

For example, I sign in to Amazon.com with my OpenID, it discovers my "Lockbox" or "Digitial Locker", I do the hybrid dance so that Amazon can dump stuff into my Lockbox, and then whenever I purchase MP3s or hardware that come with digital manuals, Amazon just passes the data directly to my Lockbox.

No need for me to download/save to my local machine.

If that's not what this is, then, oh well.

Chris
On Fri, Feb 20, 2009 at 12:10 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

So it's a proprietary initial login to an OP (that happens to do some encrypted file store stuff, possibly leveraging the proprietary token for key management). This seems useful, if yuou think that store holding the same kind of consent/audit/release logs that myopenid keeps around (tracling/tracing your communications with RPs)

Once you have a session, it happens to offer openid assertions to SPs.

The behavior seems similar to the Google BlogSpot  service, where you had to first login to BlogSpot using google proprietary means, and only then could you leave an authenticated comment on the blogspot site using some (or other ) OP. In reality Google was tracking your comment using the proprietary means, but one was present in  the OP name to comment readers.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Andrew Arnott
Sent: Friday, February 20, 2009 11:08 AM
To: Chris Messina
Cc: DiSo Project; OpenID List
Subject: Re: [OpenID] Verisign Announces Free OpenID Digital Lockbox

Sorry... this doesn't seem like OpenID authentication to me.  Verisign only lets you log into the vault using your PIP account, which although PIP is an OpenID Provider, means that OpenID has nothing to do with your authentication experience.  You can't use any openid to log in -- you just log in with your PIP username and password, and a hardware credential that costs at least $30 to boot.
--
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, Feb 20, 2009 at 10:57 AM, Chris Messina <chris.messina at gmail.com<mailto:chris.messina at gmail.com>> wrote:

I find this very interesting:

http://infosecurity.us/?p=6437

http://blogs.verisign.com/innovation/2009/02/pip_update_a_free_secure_digit.php

It's how it works over OpenID that is most compelling (though this is really just the OpenID + OAuth hybrid, minus OAuth):

http://infosecurity.us/images/openid_protocol.png

So basically it's like MobileMe attached to your OpenID, with the ability to provide delegated access!

Thoughts?

Chris
--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com<http://factoryjoe.com> # diso-project.org<http://diso-project.org>
citizenagency.com<http://citizenagency.com> # vidoop.com<http://vidoop.com>
This email is:   [ ] bloggable    [X] ask first   [ ] private

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

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com<http://factoryjoe.com> # diso-project.org<http://diso-project.org>
citizenagency.com<http://citizenagency.com> # vidoop.com<http://vidoop.com>
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090221/01d416f6/attachment-0002.htm>