[OpenID] openid connect - a high level review - thinking about what the lawyer or auditor needs

[John Bradley]

Peter,

Connect is still simple enough for the web commenting case.  It places less burden on the RP than openID 2.0  in the simple case.

It however can add social feed features like Google + or others by turning on optional features in the client.

If the use case demands asymmetrically signed assertions for non repudiation and a proof key bound to the assertion that can be done to without requiring a totally separate protocol.

This allows RP or Clients in OAuth speak to have risk based access cot roll where a person can start commenting with a low assurance credential but be able to step them up to the highest assurance if they need to access medical records or other sensitive information.   The RP can also become a attribute provider to other RP using OAuth distributed claims (Think rest STS).

The idea is to keep simple things simple, but also to make the the more complicated things possible.

In it's simple form openID Connect is arguably simpler for the RP than openID 2 and  it's certainly a lot simpler that the openID 2.0 + Oauth 1.1 hybrid that many people are deploying.

If it reassures you ITU-T SG 17 and others are well aware of openID Connect.  

Regards
John B.

On 2012-02-17, at 2:22 PM, Peter Williams wrote:

> 
> I think we got to the core of the work. It stands some change becuase it has broken with the original web paradigm. Its now addressing endpoints, and devices. It's broken with the web architecture, though. There will be some enemies there (on that score alone) - and they can be quite vitriolic.
> 
> 
> 
> If I look for competitors, as convergence accelerates, I can see ITU-T going and enhancing the Q931 and H.323 suite of protocols making their registration servers and admission control services apply to more than voip calls, video codec negotiation, bandwidght management for quality or security policy enforcement on secure voice call legs. As voice and data converge, we should expect lots of voice infrastrcuture knowhow to become re-purposed too... especially since those folks have 100 years experience in managing devices, sliced and diced into countless management domains.Ther is precious little different between a "foaf trust cicle" expressed in a blogging platform and a presence-list, in you and your friends watch each other's presence according to folk's social needs.
> 
> 
> 
> Keeping close contact with the presence protocol work (and the group-management element thereo) in cisco, for imap-accessed voice message stores or presence-based acces scontrol seems sensible.
> 
> 
> 
> but its all a far  cry from blog sites, authenticated comments, rel statements in HTML metadata to faciliate autonomy from IDPs that go bad, URLs for discovery, or semantic web vocabularies for SIOC accounts or FOAF circles of friends learned through crawling.
> 
> 
> 
> it really does seem that openid has grown up and beyond the blogging platform. It's become a stack (becuase, uinless one sticks to the old offline certs paradigm, identity cannot be distinguished from secure protocol that orchestrate an entire "association" and context of application protocols). The openid community really *is* in the space that ITU-T envisioned in its own generic upper layer security protocols working group for data (not voice, originally) networks: harmonizing layer 5 sessions, layer 6 negotiation of format, and layer 7 common services for binding and secure association management.By being less stodgy than that era with its overly layer-limited design work , openid can look to more advanced internet features to help out in a post-TCP world, in which other layer 4 protocols (SRTP.. to start with) add into the feature pot. Now DTLS starts to bring some core benefit, for connectionless designs.
> 
> 
> 
> I suppose its an open question: has openid left behind the blogging platform and gone into the communication stack space business, or has the blogging platform evolved beyond the web browser, HTMl markup and http signalling and taken blogging (as a platform now) into where voice/data are converging, anyways? 		 	   		  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120217/7b475523/attachment.p7s>