[OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0?(IIW session))
Peter Williams
pwilliams at rapattoni.com
Tue Jun 12 02:28:05 UTC 2007
> With regards to your suggestion that all this be clearly
> documented so it's easy for OpenID developers to understand
> the relationship of XRI and OpenID, I agree completely, and
> have volunteered to assist the OpenID spec editors in doing
> so. Any additional suggestions you have as to how to best
> accomplish this would be appreciated.
>
> =Drummond
How about 3 (non-normative) protocol runs that take the 3 most
interesting (80%) cases through their paces?
Choose (a) one that most resembles openid1.0
Choose (b) one that leverages what XRI is all about: local vs global
name resolution (in a p2p management domain)
Choose (c) one where the TTP-benefits of leveraging the assurances of
the xri.org proxy manifest themselves clearly to a ordinary 50 year old
user who likes AOL.
I have a (technically driven) community in my grasp that will nicely
merge with XRI - and exploit the concept of datameshes in a way that
would make the XRI designers proud. But, the whole sell as an
appropriate infrastructure will fail if the balance between (a) (b) and
(c) is biased in a way that makes its delivery forms be "unadoptable."
Right now, my intuition tells me: Rapattoni become an i-broker, license
the XRI policies and specialize them. Do NOT engage in third-party
audits, insurance or legal controls, as your customer (Mr Rapattoni -
remember you are a mere vendor!) will reject them, 100%. Do not
outsource to get a private-label XRI.org, as the costs will be way
beyond what realty is used to paying for these type of infrastructure
benefits ($0.30-$0.50 a user , per month, for ever). I have documents
that have a 15 year old shelf life, many of them contain personal
private data, the actors are all professional and licensed, and the
current telematic infrastructure loves metadata systems. Rapattoni, used
the XRI resolver to re-purpose realty's existing momentum in the SAML2
IDP arena, whilst ensuring lightweight http relying parties don't have
to jump through standards hoops to do WebSSO.
More information about the general
mailing list