I was reading James McGovern's blog today and ran across the following question -
I am still awaiting a perspective from Marc Mercuri on his thoughts of when someone presents a personal card to a relying party and it requires a workflow (Kim Cameron's blog requires a lightweight email confirmation) should the relying party integrate into BPEL or SPML and what is the best way for folks to think about this?
Before I answer the question, I want to establish two assumptions I've made, based on my interpretation of the question. The first is that 'personal cards' here is synonymous to 'self-issued cards', the second is that when referring to workflows, we're discussing workflows whose focus is to perform some process that will validate that the claims presented are accurate and the individual presenting the claims is indeed the person he/she/it claims to be.
If you've seen any of the videos I've done on information cards, you may have picked up on the fact that I'm a big fan of self-issued cards, as they allow an individual to readily share details about him/herself to recieve a a much more pleasant experience on a website or when accessing a web service. Many sites today ask you to sign up with a username and password and ask you to populate forms. With a self-issued information card, the key claims are already on the card, so it makes signing up for a site fast and painless. Then there's the personalization benefits. You could have a government site that read your postal code and provided a personalized view of "your government" - complete with data ranging from when trash is picked up on your street to legislation that may be impacting your area. You can log onto the website of an electronics store and present your card to easily get to the details for current sales in your area. There are plenty of great scenarios where a site or service can take an information card and use it - without the need for validation - to provide a better experience.
But 'plenty of great scenarios' does not translate to every scenario. There are circumstances where you will want to validate the claims that are on the card. Those scenarios are all tied to risk. And this is typically tied to risk of financial loss or an potential impact to reputation. In these cases, you'll want to take the information provided and evaluate it using a workflow.
Real World Examples
In the real world, I may call a local restaurant to deliver a pizza to my house. They take my order, my address, and my phone number. For orders below a certain dollar threshold, they'll typically just make the order and deliver it. However, if I ordered 12 pizzas, there's now more risk. And because there's financial risk that they'll waste time and resources creating 12 pizzas for what could be a prank, they'll undoubtedly call the phone number I provided to confirm that I placed the order.
If you want to publish a letter to the editor in a newspaper, you typically need to provide some evidence that can be used to prove you are who you say are. The New York Times requires that any such letter "must include the writer's address and phone numbers.". Why? Because there's risk to their reputation - as well as to the reputation of the people letter writers could claim to be - if the identity of the writer can not be determined.
Online Examples
If you've ever used Paypal, then you've taken part in a workflow where information that you've self-asserted has been validated. In this case, when you open an account they place a very small deposit (pennies) in a financial account you claim to hold. To validate your identity, you examine your account and provide the amount of the deposit. This is a very clever workflow, because it leverages an account that you have with an existing financial institution, an account that likely required your identitiy being authenticated in person, using a drivers license, passport, etc.
From a risk of reputation perspective, James pointed out what will become one of the more key scenarios, validating the identity of someone who posts to a blog. To avoid both spam and anonymous comments that could range from libelous to threatening, the owner of the blog will want to make sure you are who you say are. This is really almost identical to the New York Times' Letter to the Editor requirements.
Using Workflow
Once you've assed the nature of the risk is financial or reputation related and the specific valuation of that risk, you'll want to identify the type of workflow that will mitigate that risk for you.
Sometimes, that will be a sequential workflow, and that is typically where you will invoke one or more automated services to validate the claims in real time. For example, given my name, birthdate, home phone number, and website, you might be able to tie into some back end systems to validate the information I provided. In some cases, a workflow may retrieve additional data, which can then be used to challenge the user. This type of interaction happens synchronously and my identity can be validated during my same online session.
In other circumstances, you'll want to use a state machine workflow. This workflow is longer running than it's sequential counterpart. Once information is presented at a site or service, a communication could be made to one of the modes specified in your contact details - this is typically an email, but could just as easily by an automated speech-based service (IVR). When contacted, the workflow will deliver a code to the user. The user will then go back to the website and provide that code. This is typically accepted as a proof of identity for providing blog comments. Other examples of state machines could include a site performing related checks, for example a dating website could validate your information and then perform a check with other systems to validate that you're not married. In these circumstances, the process could be completed quickly - I could get the email right away and respond in minutes, or it could complete in hours, days, weeks, months even. If John Smith signs up for a site before he goes on vacation, and the validation email doesn't arrive until after he's left, that process could remain in the 'waiting for response from user' state for several weeks.
Back to James' question
So now, back to James' question, "should the relying party integrate into BPEL or SPML and what is the best way for folks to think about this"
I couldn't in good faith tell everyone they should implement this in BPEL. If the whole REST vs WS-* debate has taught me anything, it's that while there is tremendous value in having well thought out standards that are implemented by Enterprises, ISVs, and Infrastructure companies, there is a large segment of folks that won't use it for any number of reasons (learning curve, implementation complexity, required tools/infrastructure, time to implement, etc.).
What I'd do first is identify the workflow itself, specifically what business rules need to be validated and what integration points need to be in place to feel comfortable that the risk has been mitigated. Before we talk technology, what is the type of interactions that need to happen. Do you need to send an email and then wait for a response? Do you need to tie into back end systems to validate the information? If the workflow is based on identity validation, identify what should happen when identity validation is successful, when it is not successful (identity could not be validated) or when it fails (system exception).
Then, look at technology and determine what works best for you. For some folks this could be Windows Workflow Foundation, for others this could be BPEL, for others it could be BizTalk, and others still it could be C#, Java, Ruby, or PHP libraries that implemented the workflows directly in code. If you're writing this yourself, I'd typically advise taking whatever code you build and make it available with it's own service(s). This has benefits on a number of fronts.
I will add that there is an opportunity for someone/some group to identify some of the more common patterns (similiar to what was done with the document referenced in my last post) and then to implement and make available those patterns in the form of binaries or services.
I'm just finishing up another project at the moment, once that's out the door, I'll take a look at coding up one or more examples and then throwing the bits over onto CodePlex for people to have at it.