The ability to link people relationships to services in a very dynamic and distributed way is beginning to emerge. Envision a world where current social network relationships enable the discovery of personal services about any particular identity.
Consider the following use case: I want to notify (via the preferred mechanism of the recipient) all the people tagged as “close friends” in my “address book” or “social network”.
The problem is that while address books and social networks can know the relationship of “close friend”, they usually don’t have any way of knowing the “preferred mechanism of the recipient” to receive notifications. What’s needed is a way to “discover” via the identifiers in the “social relationship” the personal services of any particular individual.
So, what’s changing? A “new” community specification EAUT (Email-Address-to-URL-Transform) is being completed that allows an email address to be transformed (or mapped) into an OpenID. While this, in and of itself, is valuable for the adoption of the OpenID protocol, what I find really interesting is that since OpenID relies on XRDS for discovering the individual’s OpenID Provider, the mechanism is in place to discover any other service. This really enables an email-to-personal-service-discovery path that can launch a whole new set of use cases.
Even if the user doesn’t know anything about OpenID... the user’s social network could easily retrieve the OpenID’s for all of the user’s social relationships (since most are based on email address or have access to the email address). The social network could then provide additional services based on this discoverable information.
With most of the major identity providers already providing OpenIDs, all that's needed is for these players to support the EAUT specification.
[Disclaimer for my Liberty Alliance colleagues: These capabilities are already supported by combining the People Service and the Discovery Service for SOAP based deployments.]
Wednesday, August 06, 2008
Tuesday, June 03, 2008
Friend Classifications
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".
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".
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.
Thursday, March 27, 2008
"Open" Foundation Overload
With the creation of the OpenSocial Foundation, the DataPortability Group (they'll need a Foundation soon), the Information Card Foundation and of course the now established OpenID Foundation... I'm getting "foundationed" out.
I wonder if the community couldn't do something closer to OASIS and have one over arching Foundation with sub-groups working in each of these important areas. The IPR could be consistent for all the groups, but each group would have it's own "board of directors" and control the results of specifications and other efforts.
All the different focuses are important, and new areas will arise as the identity layer grows across the internet. However, convincing "management" to join multiple different organizations is a deterrent to participation.
I wonder if the community couldn't do something closer to OASIS and have one over arching Foundation with sub-groups working in each of these important areas. The IPR could be consistent for all the groups, but each group would have it's own "board of directors" and control the results of specifications and other efforts.
All the different focuses are important, and new areas will arise as the identity layer grows across the internet. However, convincing "management" to join multiple different organizations is a deterrent to participation.
Monday, March 24, 2008
Is AOL exploiting OpenID?
Today, Michael Arrington (of Tech Crunch) posted an article posturing that AOL (along with Microsoft, Google and Yahoo) are attempting to exploit OpenID by being OpenID Providers (OP) and not becoming OpenID Relying Parties (RP). I attempt to address a number of issues in this post below.
In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).
Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.
For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.
I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.
I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.
[Disclaimer: For those that don't already know, I work for AOL.]
"By becoming Issuing parties, AOL and Yahoo hope to see their users logging in all over the Internet with those credentials. But they don’t accept IDs from anywhere else, so anyone that uses their services has to create new credentials with them. It’s all gain, no pain."
In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).
"Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both [OP and RP] it can be confusing and isn’t a good user experience."
Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.
For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.
"It’s time for these companies to do what’s right for the users and fully adopt OpenID as relying parties. That doesn’t fit in with their strategy of owning the identity of as many Internet users as possible, but it certainly fits in with the Internet’s very serious need for an open, distributed and secure single log in system (OpenID is all three)."
I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.
I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.
[Disclaimer: For those that don't already know, I work for AOL.]
Wednesday, March 05, 2008
Authentication for clients
Today AOL relaunched the OpenAIM initiative. One of the key parts of this effort is supporting authentication for clients (whether those clients are native code or FLASH/AIR/Silverlight/etc). To enable this we added a 'clientLogin' API to our OpenAuth suite of APIs.
This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.
For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.
I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.
This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.
For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.
I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.
How times change
A couple nights ago my teenage son was on the family computer “working” on facebook.
I should have known.
So I asked him “How are your friends doing?” (trying to be a good parent and get my kids to talk:) ).
My son answers “I'm trying to help Judson and Samuel be friends” (names changed to protect the innocent).
I ask, “Why, are they not getting along? Did something happen?” (rather surprised).
“No”, he answers, “they can't find each other on facebook.”
I should have known.
Wednesday, February 13, 2008
Wednesday, February 06, 2008
More on Email to URL discovery
Just a couple more thoughts on this topic.
- I believe that the mapping from email domain to XRDS URL should include some addition pattern to make deployments easier. Deploying a servlet or other mechanism on the root email domain is not always easy. Having a different pattern such as xrds.my-email-service.domain would simplify deployment issues.
- While it is nice that an email to URL mapping service can provide user-centric identifier management, I don't know how much it will be used by the general public. Discovering that the email provider is also an OpenID 2.0 provider would be enough to start a directed identity flow. This I believe would be more convenient for most users.
Tuesday, February 05, 2008
Email to URL discovery
In the ongoing "world" of IdP discovery a new proposal has been made by Brad Fitzpatrick on his blog. This proposal provides for a direct mapping between an email address and a personal URL (e.g. an OpenID). The mapping between the email address and personal URL is provided by an email2url_mapping service run by the email provider. Discovery of the email2url_mapping service endpoint is found via XRI URL resolution on the domain of the email address.
Whether the user needs the full indirection capability to have an arbitrary mapping between email address and URL or is fine with allowing the email provider to be their OP/IdP is yet to be seen. It is encouraging to see consumer's UX needs being addressed.
Whether the user needs the full indirection capability to have an arbitrary mapping between email address and URL or is fine with allowing the email provider to be their OP/IdP is yet to be seen. It is encouraging to see consumer's UX needs being addressed.
Saturday, January 19, 2008
Looking at the evidence...
... it seems that we still have a ways to go when it comes to user education, user-centric identity and IdP discovery. I applaud Yahoo! and Blogger for supporting OpenID by being OpenID Providers. That is a huge step forward. However, it's interesting to note how these main stream relying party (RP) sites are implementing the user experience.
What I find fascinating about this trend is that it bypasses one of the benefits of an OpenID (built in IdP discovery). Basically, these main stream RP sites are using the "User picks their IdP" solution for determining where to send the user rather than having the user type in their IdP (yahoo.com, openid.aol.com, etc) or full OpenID URL. At the moment, this scales OK as there aren't that many mainstream providers, but either user education needs to get better so this mechanism isn't needed, or we need a different technical solution.
 From the OpenID listserv it appears that Yahoo! would prefer RPs to put a Yahoo! logo on their site that is clickable to enable Yahoo! users (and others) to login to that site (using the "directed identity" flow). |
 Also, looking at the Blogger implementation of accepting OpenIDs they list 4 main OpenID providers (I'm guessing Yahoo! will be added to the list) and then a button for "Any OpenID". |
 Maybe lesser known, but propeller.com (an AOL property) which accepts OpenIDs uses the OpenID protocol to authenticate AOL/AIM users but presents the UI as "Sign in using my AOL Screen Name". |
What I find fascinating about this trend is that it bypasses one of the benefits of an OpenID (built in IdP discovery). Basically, these main stream RP sites are using the "User picks their IdP" solution for determining where to send the user rather than having the user type in their IdP (yahoo.com, openid.aol.com, etc) or full OpenID URL. At the moment, this scales OK as there aren't that many mainstream providers, but either user education needs to get better so this mechanism isn't needed, or we need a different technical solution.
WebGuild Web 2.0 Conference
I'm participating in a panel at WebGuild's Web 2.0 Conference and Expo being moderated by Johannes. The panel will be discussing OpenID and OAuth among other things. It should be a good discussion given the recent announcements by Yahoo! and Google.
Thursday, December 20, 2007
Discovery, wherefore art thou Discovery?
The web seems "a buzz" these days with different flavors of "discovery". I've recently been hearing more and more need for Personal Service Discovery. This is coming from both internal and external customers. Two key questions are asked. (1) What is the user's preferred service? (e.g. picture service) and (2) Where is this user's specific service located. The two questions are not mutually exclusive. What I find quite humorous is that the Liberty Alliance has had a "Discovery Service" for quite some time that is capable of answering both those questions (and others). I wish I had Paul's witty way of poking fun... but alas I'm not that talented.
Here are a few recent proposals for "Discovery" services. I'm sure there are many I'm missing...
- XRI Resolution -- a mechanism for describing and querying personal service endpoints (among other things)
- XRD Provisioning Protocol (XPP) -- an XRI based mechanism for Service Providers to attach their service to a user's individual XRDS file hosted by the user's IdP
- "DHCP for Identity" -- "As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors."
- Dynamic Federation -- service provider metadata is discovered via transformation of a user identifier
- OAuth Discovery 1.0 Draft 1 -- This is really "service provider metadata" that is "discoverable".
Interesting to me is the leveraging of XRDS as a containing structure for describing service metadata amongst a number of these proposals. Anyway my hope is that as an industry we leverage all the work that has already been done while looking for ways to make things easier for users and developers.
"Standing on the shoulders of giants" comes to mind.
Soapbox: "Likely to offend some" ???
I smiled at Paul's recent post of Xmas Cards. I find it humorous that in our society we quibble over such silly things. However as I thought more about it, what really struck me was the double standard that exists but we ignore all the time.
What is it about “Merry Christmas” that might offend someone?
Is it that Christmas is equated to a Christian holiday and somehow recognizing that such a holiday exists is offensive?
Is it that the word “Christ” appears in Christmas and hence that is offensive to some?
The double standard is that it's OK to offend people who believe in God and Jesus Christ, but it's not OK for those people to use the same terms in an honoring way because they might be offensive to those who don't hold the same beliefs.
So I'm not quite sure whether I should smile or be “offended” that “Merry Christmas” is “Likely to offend some” :)
What is it about “Merry Christmas” that might offend someone?
Is it that Christmas is equated to a Christian holiday and somehow recognizing that such a holiday exists is offensive?
- This doesn't make sense to me because I would guess that the majority of people who celebrate “Christmas” do not hold to the “truths of the Christian faith”. Christmas for them is a merry time of year to give to others and receive gifts from others. It's a time to enjoy family and friends. What is so offensive about that? Would people be offended if the greeting were Happy Hanukkah?
Is it that the word “Christ” appears in Christmas and hence that is offensive to some?
- This really doesn't make sense as the same people who are offended by the term “Merry Christmas” probably use “Christ”, “Jesus”, “God”, etc on a daily basis as an expression or expletive. So if it's OK to use these terms in a way that doesn't relate to the object of the term, why would the rule change for “Merry Christmas”?
The double standard is that it's OK to offend people who believe in God and Jesus Christ, but it's not OK for those people to use the same terms in an honoring way because they might be offensive to those who don't hold the same beliefs.
So I'm not quite sure whether I should smile or be “offended” that “Merry Christmas” is “Likely to offend some” :)
From the "Feeling rather behind..." department
A few weeks ago Johannes Ernst's posted a blog entry, in which he describes a number of tiers regarding different classes of identity relationships between a business and it's partners/customers. I like the taxonomy and agree that its a good framework for communicating both identity issues and technology relevance.
I just wanted to add that Ping! Identity's proposed “dynamic federation” would perfectly suit Tier 2. It provides good secure SAML based federation while being easy to deploy. Of course, some of those 100's of affiliates might not support SAML as their identity solution so other easy to deploy mechanisms will need to exist as well.
This multiple protocol, deployment environment is the main goal of the Concordia project. The definition of these environments as use cases and then the proposed solutions will significantly help businesses integrate their affiliates in a quick and seamless manner.
Finally, I would expect that a business would want to use a single standard technology for Tier 0 and 1 as “federating” internally is a real pain.
I just wanted to add that Ping! Identity's proposed “dynamic federation” would perfectly suit Tier 2. It provides good secure SAML based federation while being easy to deploy. Of course, some of those 100's of affiliates might not support SAML as their identity solution so other easy to deploy mechanisms will need to exist as well.
This multiple protocol, deployment environment is the main goal of the Concordia project. The definition of these environments as use cases and then the proposed solutions will significantly help businesses integrate their affiliates in a quick and seamless manner.
Finally, I would expect that a business would want to use a single standard technology for Tier 0 and 1 as “federating” internally is a real pain.
Subscribe to:
Posts (Atom)