A colleague of fine was mentioning recently that it's "hard to keep contacts separate (work/friends/family)" on all the different social networking sites. I couldn't agree more. This is made additionally hard by the fact that each "social network" site imposes their own "classification" of friends. These classifications are not mine and I have to morph my view of my contacts into these imposed rigors.
I would much prefer to be able to manage my contact classifications as "tags". Taxonomies force me into specifying that a contact can be in only one group. I have work colleagues that are also friends. If I could "tag" all my contacts with my own classification scheme and then use that when interacting with social networking sites, life would be much simpler.
I guess this is the "promise" of the "Open Social Web".
Tuesday, June 03, 2008
Thursday, May 15, 2008
XRDS for Information Cards?
One of the topics that came up at the most recent IIW (IIW2008a) in a couple of sessions, is the concept of allowing an RP/SP to describe it's services and requirements in a passive way. The goal being to allow "Identity Agents" to provide a progressively better user experience. A user should be able to interact with the RP in a normal "dumb" browser session, but also allow tools (e.g. an Identity Agent) to provide a much more seamless experience.
In an InfoCard Capabilities session, lead by Pamela Dingle, there was some discussion about how to do this technically. The following is a proposal for one way this might be accomplished.
The "Relying Party" would need to...
The "Identity Agent" would need to...
What could the XRDS markup look like for an InfoCard relying party?
First we need to define some <Type> URIs to represent different metadata characteristics of the relying party relating to InfoCards. Here are some possible examples...
An example XRDS document could look like...
In an InfoCard Capabilities session, lead by Pamela Dingle, there was some discussion about how to do this technically. The following is a proposal for one way this might be accomplished.
The "Relying Party" would need to...
- define an XRDS file describing identity protocols supported, services provided, and other metadata
- allow for discovery of the XRDS file through normal XRI resolution (section 6)
- additionally allow for discovery by adding a
<link rel=”xrds.metadata” target=”location-of-xrds-file”/>
in the <head> section of the pages provided by the relying party
The "Identity Agent" would need to...
- look in web page dom for the xrds.metadata link
- retrieve and parse XRDS document
- find supported identity mechanisms and endpoints
- invoke card selector
- allow user to select card
- post card to endpoint specified in the XRDS document
What could the XRDS markup look like for an InfoCard relying party?
First we need to define some <Type> URIs to represent different metadata characteristics of the relying party relating to InfoCards. Here are some possible examples...
<Type>http://infocardfoundation.org/policy/1.0/login</Type>This type identifies the service/endpoint describing the claims required for login.<Type>http://infocardfoundation.org/policy/1.0/registration</Type>This type identifies the service/endpoint describing the claims required for registration.<Type>http://infocardfoundation.org/service/1.0/login</Type>This type identifies the service/endpoint where the login token should be sent.<Type>http://infocardfoundation.org/service/1.0/registration</Type>This type identifies the service/endpoint where the registration token should be sent.
An example XRDS document could look like...
<?xml version=1.0 encoding=UTF-8?>
<XRDS xmlns=xri://$xrds>
<XRD xmlns=xri://$XRD*($v*2.0) version=2.0>
<Type>xri://$xrds*simple</Type>
<!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
<Service>
<Type>http://infocardfoundation.org/policy/1.0/login</Type>
<URI>http://sp.example.com/policy/login.xml</URI>
</Service>
<!-- Service specification that identifies the endpoint of the infocard policy for registration claims -->
<Service>
<Type>http://infocardfoundation.org/policy/1.0/registration</Type>
<URI>http://sp.example.com/policy/registration.xml</URI>
</Service>
<!-- Service specification that identifies the endpoint for submitting login claims -->
<Service>
<Type>http://infocardfoundation.org/service/1.0/login</Type>
<URI>http://sp.example.com/login</URI>
</Service>
<!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
<Service>
<Type>http://infocardfoundation.org/service/1.0/registration</Type>
<URI>http://sp.example.com/registration</URI>
</Service>
</XRD>
</XRDS>
Thursday, May 08, 2008
How times change
I must be getting "old" as I find the following humorous.
The other morning my daughter said she was doing a report on "family life" in the 1980's. My wife (who likes to research things) grabbed her laptop and started looking information on the 1980s. She finds a site and reads something like...
To which my daughter responds... "What's Pac Man?"
The other morning my daughter said she was doing a report on "family life" in the 1980's. My wife (who likes to research things) grabbed her laptop and started looking information on the 1980s. She finds a site and reads something like...
In the early 80's, the computer game "Pac Man" was released in color making all previous black and white games obsolete.
To which my daughter responds... "What's Pac Man?"
Friday, May 02, 2008
Community Convergence
There has been much talk in our industry about Technical Convergence (i.e. moving toward one protocol for a particular task). However, before there can be Technical Convergence, there needs to Community Understanding and potentially Convergence.
That's why I'm excited to be attending the Internet Identity Workshop in Mt. View, CA the week of May 12. This is one of those places where Community Understanding takes place and sometimes even Community Convergence.
Hope to see you there!
That's why I'm excited to be attending the Internet Identity Workshop in Mt. View, CA the week of May 12. This is one of those places where Community Understanding takes place and sometimes even Community Convergence.
Hope to see you there!
Wednesday, April 09, 2008
Discovering OpenID Relying Parties
Yesterday Paul blogged about his experience logging into Wishlistr with his Yahoo OpenID.
I commented on Paul's blog that it might have something to do with OpenID Relying Party discovery. Section 9.2.1 of the OpenID 2 spec defines how to verify the return_to URL in an OpenID authentication.
I tried requesting the XRDS description from Wishlistr to no avail (curl --header "Accept: application/xrds+xml" -i -v http://www.wishlistr.com ). Section 13 of the OpenID 2 spec makes it a SHOULD for relying parties to support discovery. With the adoption of OpenID 2 just beginning to ramp up, relying parties supporting discovery may be a ways away.
Please note that this is just my guess as to what might be causing the warning. There are many other possible causes as well. Though I do believe that RP discovery is a key feature of OpenID 2.
But, when I tried to do so, Yahoo! showed me the following warning
What would Wishlistr need to do to 'confirm its identity' to Yahoo such that users wouldn't see this (likely enthusiasm killing) warning?
I commented on Paul's blog that it might have something to do with OpenID Relying Party discovery. Section 9.2.1 of the OpenID 2 spec defines how to verify the return_to URL in an OpenID authentication.
OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party.
I tried requesting the XRDS description from Wishlistr to no avail (curl --header "Accept: application/xrds+xml" -i -v http://www.wishlistr.com ). Section 13 of the OpenID 2 spec makes it a SHOULD for relying parties to support discovery. With the adoption of OpenID 2 just beginning to ramp up, relying parties supporting discovery may be a ways away.
Please note that this is just my guess as to what might be causing the warning. There are many other possible causes as well. Though I do believe that RP discovery is a key feature of OpenID 2.
Thursday, April 03, 2008
Identity API for the Internet Identity Layer
Patrick Harding has a great post today on "A Model for an Internet Identity Layer". He breaks down the Identity Layer into three sub-layers. It addition he points out that...
Interestingly enough, Phil Hunt talks specifically about this issue his post yesterday.
The API the Phil references is the IGF AttrSvcs API that is part of the openLiberty project. I believe this API address a key component of the "Identity Interface" and "claims sub-layer". It's going to be very important to track policy at the "Identity Interface" and the Identity Governance Framework addresses these issues.
In addition, we have found that applications developers are spending far too much time concerning themselves with the lower levels of the identity layer. App developers need to be able to leverage a standard identity API interface that interacts with the claims sub-layer. The developer should receive all the information it needs via this API directly from the claims sub-layer. This information obviously manifests as claims and as such means that application, by default, must become claims aware. Today, this likely just means user attributes or a role value, but in the future this may include actual authorization decisions. Leveraging a standard API that allows an application to plug-and–play with the identity layer offers some future proofing as the identity protocols underneath change.
Interestingly enough, Phil Hunt talks specifically about this issue his post yesterday.
You see, the idea isn't just to support identity privacy and governance, but to create an application identity API (aka Attribute Services API) that allows applications to become decoupled these issues of having to support all the protocols and technologies out there. It lets the enterprise's decide how and when applications should access identity information and by what means.
The API the Phil references is the IGF AttrSvcs API that is part of the openLiberty project. I believe this API address a key component of the "Identity Interface" and "claims sub-layer". It's going to be very important to track policy at the "Identity Interface" and the Identity Governance Framework addresses these issues.
Wednesday, April 02, 2008
Trust relationships in OpenID
A while back I wrote the following to the OpenID general list serv.
As I see it there are 3 parties involved in the transaction: the user, the OP and the RP. There is some trust/risk factor associated with each relationship.
From the user's perspective they "trust" the OP (either because they want to spam and so are using an OP that makes "false assertions", or because they trust the OP to protect their authentication credentials and represent them correctly on the web). The user may or may not trust the RP, but by logging in they are making some level of trust/risk assessment.
From the OP's perspective the user represents some risk/value metric (too many "bad" users and the OP gets blacklisted). The OP protects that risk by potentially verifying email or cell number, supporting PAPE and other strong authentication methods, etc. The OP also has a risk/value metric with the RP though this is probably not super important right now. I can envision a smart OP warning me about authenticating to an RP that it some how determined is not "trustworthy".
From the RP's perspective, they have a risk/value metric on the user (e.g. Is the user going to be a good citizen of my community? Are they going to abuse the resources I provide? How much effort do I want to put into detecting "bad apples"?). The RP also has a risk/value metric on the OP (e.g. When the OP says they support the PAPE extension do they really do it?). Finally the RP has a risk/value metric on the resource/service they provide. From a business perspective I don't believe it's wise to blatantly "trust" the user if the resource/service is highly valuable (e.g. moving funds between accounts). Most users today don't have the sophistication to make good decisions.
Ok, so maybe I was a little unfair in my characterization of “most users”. I was trying to say that I don't believe many users know how to chose a good OP. In fact many will just use an OP they already have (which puts pressure on those OPs to be good citizens; that's a “good thing”). So, if an RP has a high trust metric with the user's OP, then they can more confidently trust the user as well. On the RP side its really an assessment of risk against the “User:OP“ pair.
Subscribe to:
Posts (Atom)
