Empirical

In a 1793 letter to King George III declining a trade relationship, Chinese emperor Qian Long bragged

our Celestial Empire possesses all things in prolific abundance and lacks no product within its own borders.

and

I set no value on objects strange or ingenious, and have no use for your country's manufactures.

Sounds like one of the big public OPs.

Perhaps its relevant to note that the insular attitude did not ultimately serve China well.

Barack had better win

I don't want to be hanging around in Chicago with a bunch of despondent losers.

Looks like an SSO redirect sequence

Flights for upcoming travel

If only the 'user agents' were 'business class'.

Anthropoprotocolism

Anthropoprotocolism (ăn'thrə-pə-pro-to-kul'iz'əm)
Function: noun

: Attribution of human motivation, characteristics, or behavior to inanimate protocols, identity standards or deployments. To criticize deployments of OpenID for whitelisting and thereby breaking the 'spirit' is to anthropoprotocolize OpenID.

See - ridiculous

Much as I love a Microsoft rant

an article that blasts Microsoft for Live ID not issuing card based identities should acknowledge the card support already in Live ID.

Separately, has UProve technology been integrated?

Put your birthday into a managed card and you can prove that you’re over 16 for a shopping site without handing over details that could help someone hack your bank account if the site loses its customer details on a USB stick, because the site only gets the assertion that you’re old enough, not the actual day, month and year.

This bit has me stumped

Is it because OpenID is accepted by a lot of sites? So are information cards,

I will submit another possible explanation as to why Microsoft is currently hiliting their OpenID support in Live ID, more so than information cards.

Perversely restrictive list.

White lies

From Seed Magazine, an article with a moral for IdPs, i.e. deceiving those who place their trust in you only works as long as they trust you.

Homeopathy would appear to be the equivalent self-asserted model, ie. users fooling themselves without the benefit of an authoritarian 3rd party in a white coat.

Street wise

Generally when I travel I prefer to walk from place to place (e.g. hotel, meetings, bars etc) as much as possible. But in big cities it's not always easy to know beforehand how practical this will be.

But for next week's various Liberty Alliance event locales around Tokyo, I've been able to 'walk' the routes 'to and fro' using Google Maps Street view.

 

As far as I can tell, walking will be practical - with sidewalks where I need them, no insurmountable freeways, and appropriately spaced konbini along the routes.

Although I am a little worried about that delivery van headed right at me.

Getting warmer

Warmer .... warmer.

Strange that when he could, with reasonable justification, play the 'meta card', Don chose to avail himself of it only sparingly.

Perhaps he, Kim, and Mike need a sync-up on messaging?

I should talk, sometimes NTT Corporate Marketing and I are so far apart it's like we speak different languages.

In defense of heterogeneity

A Seed Magazine article examines the dangers of homogeneity to Earth's diversity and 'resilience'.

Project Concordia is a recognition of the value of diversity in identity management.

Who the #$@&* is Patrick Heuchenne?

Update: Patrick resolves the mystery as to our connection, it was through Project VRM.

I'm always impressed by the 'You may also know ...' feature of social networks - it seems a bit spooky how they can guess who else I might have a connection to (yes, even trivially simple algorythms can create spookiness).

The capture below is from Plaxo.

Of the 9 suggestions, 8 could be considered relevant - I either do indeed know the individual, or might want to pretend to (were I not already connected with them multiple times over in other networks).

But my pending friend Patrick had me stumped. A Google search didn't clarify.

Then I found him on Linked In.

And I do indeed feel a connection - just the other day I was explaining to my kids that 'Buying or selling is at the end of a transformation process which converts subtle experiences into tangible and physical ones'. That is freaky.

Thunderbird thinks Obama is a scam

but I don't.

You have to admit the mail has some of the same characteristics as spam though, e.g. request for money, claimed urgency, appeal to male sexual insecurity etc.

If I were the suspicious type, I'd think this was a Republican plot, i.e. subvert Democrat fund raising through manipulation of spam filtering.

Going to be a busy 3 days

Connectid endorses McCain/Palin

After carefully examining the potential for identity-based satire over the next 4 years (admittedly likely less for McCain) Connectid has decided to throw its weight behind the campaign that offers the greatest opportunities.

The other guys give me nothing to work with (other than to suggest that MyBO is a less than optimal acronym for a profile page)

I'm Paul Madsen and I approve this message.

Of course

If I could teach newcomers just one thing about federated identity, they would probably want a refund for the tutorial series.

Ignoble

There is currently no Nobel Prize for federated identity.

Don't tell me you are naive enough to believe that this situation won't change pretty darn quickly if the Swedes ever get their act together?

Cross-domain reputation portability

I switched dentists recently, the old one seemed to see me more in terms of my coverage than my teeth, i.e. what procedures are allowed under the plan, not what are needed.

I chose my new dentist based on my previous experience with him as, at least initially, a team mate on some Ultimate frisbee teams. It was his reputation as a strong defender with a nice flick, more so than any reputation he might have as a dentist, that drew me to him, his reclining chair, and instruments of pain.

You know what they  say about Ultimate - it doesn't build character, it conceals it (or something like that).

Successfully transferring reputation across domain boundaries based on sports like volleyball will likely vary.

There is help out there

If you know an RP that you feel may be making bad trust decisions about their partner IDPs/OPs - it's difficult to know what to do.

Should you intervene? You may worry that talking to them will be seen as 'butting in'. Will they be offended, embarassed, litigious?

Does the RP even have a problem? The following are warning signs that an RP you know may have a federated identity gambling problem

1) Do they constantly talk about arcane things like PAPE, or AuthnContext?
2) Do they trust unknown IdPs/OPs in the hope of 'winning back' lost customers?
3) Do they lie to family and friends about their federated identity activities?
4) Do they neglect local sign-on mechanisms in favour of federated login?

If you have a friend RP demonstrating any or all of the above signs, there is help - a site to help friends, help friend RPs.

The other assurance

The default SAML SSO model has a RP trusting a possibly unknown User based on the IDP (which the RP does know and trust) saying 'He is OK'.

The hard line user-centric model has an RP trusting a possibly unknown OP based on the User (which the RP may know and trust) saying 'He is OK'.

Of course, it is meaningless to say 'trust' without adding 'to do X', i.e. trusting someone means believing they will act in a certain way in a certain situation.

A SAML RP trusts the IDP to identity proof the User initially, to run a good ship with respect to internal processes, and to authenticate the User in an appropriate manner. Importantly, there are mechanisms and syntax by which the IDP's abilities in these respects can be quantified, in order to allow RPs to make graded trust decisions about the IDP (and consequently about the Users).

In the hardline user-centric model, the burden of assessing the OP's security processes would seem to fall on the User, i.e. it's the User who will vouch for the IDP to the RP by saying the equivalent of 'I've checked out their server farm, we're good to go'.

Unfortunately, there does not yet exist a framework by which the skills and expertise of different typical Users for performing security reviews could be quantized and assessed in order to allow the RPs to make an informed trust decision about the User (and consequently about an ertswhile unknown IDP).

Here is a rough first draft of such an assurance framework

• Level 0 - the User has absolutely no expertise in assessing the security processes of IDPs
• Level 1 - there is no Level 1
• Level 2 - there is no Level 2
• Level 3 - see Level 2

Were an RP to be armed with this information, the hard line model is viable.

I imagine a browser extension advertising User's assurance levels to the RPs they visit, so as to inform the RP's decision to trust that User's expertise in reviewing the OP that they present. There could even be certification programs run at local high schools, etc. Perhaps even badges?

On a whim

motivated by a thread on the OpenID list, I tried to use my bonoboch.mp OpenID at Microsoft HealthVault.

 

I did not of course expect it to work, but I did expect a more illuminating error message.

I think an average user might be forgiven for thinking that this would work the next time, when 'communication problems' are cleared up.

Bad news

When applied to Web SSO, Einstein's Theory of Special Relativity predicts that the advantages to users are minimal at best.

Consider two users Alice & Bob, both of whom having successfully simultaneously authenticated to the same IDP, are hoping to browse to the same service provider. Alice will avail herself of SSO from the IDP, while Bob will get there the old fashioned way, i.e. use his bookmark for the SP and once there, log in with is password.

It's undeniable that, using SSO, Alice will get to the SP before Bob. But there is a trade-off for her.

Special relativity constrains Alice's combined motion through space & time (specifically that their sum must exactly equal the speed of light). As Alice is 'travelling' faster than Bob, her motion through time must slow down to compensate - and time will consequently be slower for Alice.

Initial calculations show that any actual speed advantage for Alice will be almost exactly negated by her perception of the SSO taking longer than it actually does - this a result of the time dilation.

I call this the 'Theory of Special Redirectivity'.

Let my people go

I submit the above as a tag line for social portability.

ID Commons Activities - Updated

Pap (regurgitated)

Somehow, I find it more interesting to read about somebody's daily hygiene regimen and other equally absorbing news when told by someone else.

Weird

From the add contacts page at bonobochi.mp

All Your Friends Are Here

With Chi.mp, you can keep all your friends in one place, making it simple to find people when you need them. Grab your contacts from services you subscribe to, your current address book, or add a new contact by hand.

Then you can combine them easily so you know that Daveman692 is really your friend Dave who likes scuba diving and has the crazy hair. Then add tags so you group and find people according to special interests.

Was this tailored to me? Because I do indeed know a daveman692 who likes scuba and sometimes has crazy hair (not that I'm judging).

Or is it simply a private joke between members of the cool end of the identerati continuum?  Designed to mock the uncool end? Nice, very nice.

Monkey Business

I'm proud to announce bonobochi.mp.

I've always felt a affinity for the Bonobo chimp, so it felt right to claim them for my domain.

The species is distinguished by relatively long legs, parted hair on their head, a matriarchal culture, and the prominent role of sexual activity in its society.

I could do worse for an epitaph.

A feature I like is the ability to toggle between viewing my profile page as myself, and as a member of the unwashed hordes.

Offline, it's my wife who informs me as to how I'm currently appearing to others (e.g. people are laughing at you, I can't believe you wore that sweater, etc), so its nice to have a parallel mechanism online.

Reputation Filter

The recent surge in numbers of blog posts discussing reputation has forced me to specify filter criteria in my feed reader - I simply can no longer keep up with the traffic.

grep "social"

Alas, neither Gerry's post nor Radovan's post met the criteria. I do wonder what arguments they made ....

Some attributes are intrinsic to a user, some extrinsic, emerging from that user's social interactions with others. The latter are candidates for reputation, the former not.

Somewhat related, based on intrinsic value, there are bargains (i.e. intrinsic > market) to be had in the turbulent equity markets. Warren Buffet has a reputation for finding them.

A question of faith

Jeff beats me to it, relating particular religions to particular identity systems.

I'd add to Jeff's list the following:

• Passport - any of the monotheistic 'Big 3', e.g. Judaism, Christianity, Islam with their whole 'No other gods before me' shtick 
• UProve - The Mormons. Stop preaching at me that my soul is lost, I'm doing just fine thank you.
  
• XDI - Rastafarianism . I may not buy into the premise, but it looks like a good time.
  
• VRM - Buddhism. Not a religion per se, more a philosophy of personal growth and empowerment.
  

What he said

Gerry takes the ball and runs with it.

Subjective vs objective is the ultimate determinant of whether an attribute is something for which a user can have a 'reputation for', and is consistent with both my other conjecture about reputation (reputable attributes are not fixed), and Robert's comment (they can drop to zero).

Gerry's brief rumination on reality makes me think of a joke - Two quantum physicists probably go into a bar.

Sorry 'bout that.

Reputation Conjecture 2

For a given attribute to have a reputation aspect, it must be possible for the entity concerned to, through their own actions, manipulate that attribute.

I can try to change my reputation for cynicism.

I can't try to change my 'reputation' for being 6'.

The Desert Island Rule

Much discussion of reputation, what it is, what it isn't on the ID Gang list.

I propose the following test for whether a given attribute can have a reputation aspect.

Were the entity in question to be located on a desert island with no social contact with others, would the value of the attribute in question be impacted?

If I was on a deserted island with no social interactions, it would make no sense to talk about my reputation for trustworthiness or dependability (both admittedly recently at all time lows) because there would be nobody else with whom my interactions could be assessed for trustworthiness. Likewise, a business wouldn't be able to develop a reputation for courteous customer service if it was stuck on the island and unable to service its customers.

On the other hand, my age or weight (although I do expect I'd lose some weight, all the Survivor contestants do, which would be nice) on that island would be the same as if I was at home - they are not social constructs. Consequently, I can't have a reputation for being either 44 years old or 165 lbs (ahem).

Is this 2 factor authentication?

I know that the authentication relies solely on the implanted chip, so technically it is one factor, but surely there are so few people in the world this crazy that the effective authentication strength is greater?

I am currently using it to open my handgun safe for instant access. I can have a gun in hand in one second in blackness without fumbling with buttons or codes.

What sort of numbers are we looking at? Let's say there are 100 million in the US who would think this is a good idea for enabling fast, easy & indiscriminate firearm access. That cuts the pool of possible authenticators almost in 3 right?

I'VE BEEN TOLD THAT RFID IS THE MARK OF THE BEAST?

I think SAML needs to write up a new 'beast mark' Authentication Context class and do it fast.

Pantheon of the gods

Deism: the belief that the Universe was created by some supernatural power, but that this entity does not play an active role in the Universe today.

Deism asserts that there needs to be some supreme authority to 'get things moving' but minimizes the role of that authority to be involved in the subsequent day to day goings on, i.e. enjoying that seventh day of rest forever.

For web identity, this is the UProve proposition. To a lesser extent, Liberty's Advanced Client.

Theism: the belief that the Universe was created by some supernatural power, and this supreme authority even now playing an active role in day to day happenings.

Like deism, theism postulates a creator, but has that same creator actively participating in the Universe's happenings once initiated, i.e. answering prayers, causing floods, chatting with Presidents etc.

This is the SAML Web SSO, Managed Cards, & OpenID proposition.
  
Atheism: the rejection of theism and deism.

Atheism rejects completely the necessity or relevance for some deity mediating between individuals and the wonders of the Universe.

Think Personal Cards.

Update to my Google Health Conditions

I realized it had been a while since I updated the list of conditions I maintain at Google Health with their current status.

Changes were constrained to the 'A's.

As yet, I've seen no evidence of Google having monetized my health records. They are obviously waiting for the right opportunity.

Well he started it!

Pam's haiku collection feels too much like my mother telling me to stop fighting with my brothers.

Mom: OK, now calm down and tell me what the problem is.
Me: (blubbering) Well, they have started this club, and they want to call it the 'metasystem', and I said that's not right because it's scoped for just infocards and then they...
Mom: Slow down a bit. So they want to use the metasystem concept in their name and you think that this is inappropriate? Is that it?
Me: Uh huh, and then they said that I couldn't even join their club cuz I had my own baby club ...
Mom: (to brother) OK, your turn. What's this about a club?
Brother: Ahh mom, it's just a place for me and my buddies to hang out.
Mom: That's fine. But 'metasystem'? How many times have we talked about using nomenclature to exclude your brother?
Brother: But Mom, he always tries to bring in that OpenID guy.
Mom: (to me) What did I tell you about not playing with that kid? Why don't you ever play with Liberty from down the road? She's fun isn't she?
Me: Ahh mom, Liberty is alright, but lately all she ever wants to play is her ID TBD game.

FUIML

The recently released research from Google and Yahoo on best practices for federated UI makes me think we need a markup language in order to differentiate the various models.

Enter "Federated UI Markup Language" (pronounced 'Fweemel').

And it's even based on an existing standard!

The design objective of the User Interface Markup Language (UIML) is to provide a vendor-neutral, canonical representation of any user interface (UI) suitable for mapping to existing languages. UIML provides a highly device-independent method to describe a user interface. UIML factors any user interface description into six orthogonal pieces, answering six questions:

What are the parts comprising the UI?
What is the presentation (look/feel/sound) used for the parts?
What is the content (e.g., text, images, sounds) used in the UI?
What is the behavior of the UI (e.g., when someone clicks or says something)?
What is the mapping of the parts to UI controls in some toolkit (e.g., Java Swing classes or HTML tags)?
What is the API of the business logic that the UI is connected to?

Inevitably, there will be other proposals for federated UI markup languages. I expect we'll see something that will be styled as "composable & modular". Maybe another will be a Interface Metasystem Interoperability ...... no, probably not.

Username Check?

Forget usernames, I need to know where I've used my password.

Have to think this could be useful for phishers.

Geode

Geode is a Firefox extension for geolocation.

As I understand the process, whenever a web site indicates it's looking for your location , the extension uses a W3C location API to query Skyhook Loki, which determines your location from WiFi triangulation.

Once Geode has your location from Loki, it shares it with service providers, like a sample FoodFinder

 

Before sharing with an SP, Geode asks you for your granularity privacy policy.

On two separate trials visiting Yahoo FireEagle, I specified 'Exact Location' and 'Neighborhood'.

For the latter, FireEagle appeared to know my location to the same accuracy as for the former, even though I specifically did not select the 'Remember my decision' box.

The same experiment for the FoodFinder app worked, so it would seem FireEagle is doing its own tricks to remember.

For many applications, ultimately more important than a user's location (whether obfuscated or not) is whether they are near to some particular place. The privacy principle of minimal disclosure would argue that if the SP really doesn't need the full location, but only a yes/no to a question of 'Is he within 2 km of X'?, then they shouldn't get the full location.

I don't see support for this sort of 'test position' method in the W3C API.

A Social Experiment

I lived in Canberra, Australia as a teenager. My best friends then were Greg Parsons and David Barnsley.

For the past 10 years I've tried to use various Web mechanisms to track the two of them down, and reestablish contact.

No luck so far.

How might I game (in a non-adversarial manner) the search engine algorythms such that, if and when my two friends search on their own name (which I am confident of because they were both pretty fond of themselves when I knew them), that this posting would turn up?

How many links to this post would drive the ranking up such that it would rise above the 'David & Greg' froth?

The authority of the linkers will be key (thanks for the thought Conor, but probably not relevant).

Canadian Identity Proofing for Federal Election

as noted by Dick.

Only in Canada

Only in Canada would organizers of a contest to pick the new musical score for a weekly hockey broadcast worry about spurious votes.

There are rumours of another vote happening simultaneously. Poor scheduling.

Let me see if I have this straight

Marriott is contacting me in order to ask permission to contact me?

Incompatible UI?

Yahoo's just released UI research for OpenID Best Practices recommends distinguishing between local and federated UI.

Many users were confused by Login screens which contained both the traditional username/password login form, and the OpenID URL textbox. Some users thought that they needed to enter a username, password, and an OpenID to sign in. To reduce confusion, we recommend that Relying Parties clearly indicate that users have a choice of logging in using traditional methods, or by using an OpenID

This seems incompatible with Google's omnibus proposal - which conflates both.

(If I worked at Yahoo! I bet I'd get tired of writing the '!' over and over in every correspondence or document)

GooglUI

Random thoughts on the proposal from Google's Eric Sachs for a consistent login ceremony at service providers

1)  The number of combinations that that single UI is expected to support is daunting

- whether the user is new or existing
- whether the user is local or federated
- whether the user enters an email address, an OpenID, or a domain


Is it over reaching to expect that a single textual change to the Buy.com UI model (which was designed to support only a fraction of the number of combinations) will  adequately support the additional ones?

2) It's by presenting an email address to the RP that the User drives IdP selection (or kicks off a local registration/login). And choosing an IdP can be equivalent to choosing a persona.

But the suggested prompt of 'Enter your email address' doesn't, I think, make this as clear as it could, i.e. that a consequence of whatever email the User provides will be them presenting a different persona to the RP (different values for shared attributes etc)

Clearly Users are more and more comfortable presenting different email addresses in different contexts, but I'd argue that their current choices are driven more by spam routing than by the desire to present a different view of themselves appropriate to a context.

3) although the doc refers to OpenID, there are many references to 'trusted IDPs' - implying that the RP has a whitelist.

If the RP didn't have a whitelist to check provided email addresses against, the RP wouldn't be able to tell the difference between

a) a user trying to create a new local RP account against their email provider address
b) a user trying to kick off OpenID SSO through an unknown (to the RP) OP

because in both cases the User would select the 'No, help me log in' option.

4) A paragraph about trust models and assurance requirements seems out of place in a proposal for UI

"While Google has had good results with this user interface, it still requires the RP to trust the IDP.  In some cases, it will be difficult for the RP to trust any IDP. For example, Google offers the Google Checkout service which lets users pay for purchases they have made on other websites.  This requires Google to meet many special certification requirements that traditional e-commerce site do not need to worry about, including special certification on how we authenticate our users.  Online banks similarly have certification requirements on how they authenticate their end-users."

How an RP indicates to the User 'Sorry, I can't do business with the IDP you suggested' would be an important piece (and one ripe for IDP placement battles)

5) The doc suggests there is a privacy risk associated with opaque identifiers

If the IDP supports using opaque identifiers ..... The primary privacy concern of this option for some users is that if they are logged into the same IDP on two different machines, then RPs can track their activity across those two computers. Of course some users may not want to be tracked in that manner, while others will consider it a helpful feature to make their Internet experience more "portable" across computers

I'm missing something. In a non-federated case, if the User didn't want the RP to track them across computers, then they'd have to create different RP accounts for each computer. In a federated scenario, if the User wanted the same privacy, then they just need to ensure that the IDP provides a different opaque identifier each time they access the RP.

.

Threads

Tieing them up.

1. TrustBearer is picked by Microsoft HealthVault as an approved OP.
2. TrustBearer is proud of the distinction (perhaps seeing Msft as a strategic partner?)
3. TrustBearer CEO vows to do whatever is necessary to keep strategic partner happy (educated guess)
   
4. Along with others, TrustBearer proposes an extension to PAPE that would allow OPs to describe specific authentication mechanisms, rather than the PAPE 'policies'

Is it reasonable to assume that a certain strategic RP wants to see information as to particular authentication methods when a User SSOs in from TrustBearer - PAPE's abstractions not sufficient?

I love the smell of PAPE in the morning

Thinking more about the PAPE-AM (please note cute time of day reference in title) model, which is to describe the specifics of an authentication mechanism rather than the more abstract security characteristics that that mechanism can engender (the PAPE model).

As I understand it, one of the reasons that PAPE originally disavowed the 'specific method' model is the concern that, for the OP to disclose this fact to RPs would present a privacy risk to the User, as the knowledge would give a malicious RP a (theoretical) advantage in hacking that User's account at the IDP.

I've never bought this argument:

1. Given OpenID's (and the SAML Web SSO profile to a slightly lesser extent) well-known vulnerability to phishing, if I was a bad RP, I can think of an easier way to get the User's IDP credential.
2. security through obscurity? 

And even were I to grant the possibility that the RP might misuse the information, why should this particular bit of PII be treated any different than another attribute, e.g. my shipping address. Minimal disclosure is definitely applicable here, but let's acknowledge that different RPs will have different views of just what level of detail is minimal and still useful.
 
Separately, I don't buy at all Mike's argument that PAPE, as it is a 'policy' extension, is not the place for expressing specific authentication mechanisms. It's all policy. And it's a distinction that WS-Security Policy is happy to ignore.

Just sprinkle some 'eh's

Some face time with the candidate

Are you sure you want to send that <saml:Response>

This sort of functionality could have been useful within Google itself.

String theory

From John, Drummond ties up what I assume to be the initial IMI TC meeting in London.

Great, now we'll need to worry about 'knot harmonization'.

Just don't try to convince me that the clove hitch isn't applicable in all situations - it  just needs to be profiled a bit.

Bowline? don't make me laugh - nobody will use it if they need any assurance that it would hold.

Drummond, was that American string brought over in your knapsack, or was it purchased locally (and thereby able to satisfy the tougher EU privacy requirements)?

Work/home

Let's hope not.

Slight tweak to Google's UI Model

Google proposal

One issue with this model is that, for a User who has a Buy.com password but nevertheless wants to login through a federated IDP, the UI forces them to ignore what they know to be true.

So why not instead present their choice more positively?

Tweak

Bootstrapping the Identity Metasytem (you know, the big one, not that card specific one)

Update: new title reflects recent nomenclature discussions.

Presentation from DIDW 2008

DIWD Concordia

Identity Experience Index

We need something like this for identity.

The 'Identity Experience Index' would be calculated by factoring in the client's

• processor speed
  
• connectivity
• availability of selectors
• UI constraints
  
• existing authentication sessions
  

At any one time, the right identity mechanism would be chosen based on the IEI.

For instance, if I'm trying to purchase some Senators merchandise at a hockey game with my mobile phone, but I get no signal, then the low connectivity value would dictate either a personal information card or a Liberty Advanced Client type interaction.

I will not rest until we have 3 layers of identity selection happening on the client

1) select an information card
2) select an information card selector
3) select an identity mechanism/protocol

Multi-Device Single SignOn

As the name suggests, its SSO, but across two devices.

Liberty Alliance just released the MD SSO deployment guideline detailing how to use existing ID-WSF pieces to meet this use case

PAPE-AM

A proposal for an evolution to PAPE that digs a bit deeper than PAPE's policies - specifically

specific assertions about how a user authenticated to an OP were needed.

The proposal, in that it delves into the details of the authentication mechanism , feels closer to SAML Authentication Context than existing PAPE (indeed, the original PAPEists specifically rejected this model, citing, amongst other issues, 'privacy concerns')

• method = {password, otp, pki, biometric}
  The authentication method must contain one or more of these elements in the set. We chose 4 of the most common authentication methods today. This set could be expanded in the future.
• otp.info = {mode, token_type, consent, length, encoding, algorithm}
  This parameter contains detailed information about the type of One-Time Password token and service that was used during authentication. Consent is defined by the additional factor of authentication needed to use the OTP (such as a passphrase or biometric).
• pki.key.info = {storage, algorithm, policy, consent}
  This parameter contains detailed information about the private key used in a challenge-response with PKI authentication. (e.g. “hardware”, “RSA_1024″, “not exportable”, “passphrase”)
  

'Biometric' seems optimistic.

+1

to Kim's suggestion.

If it were anybody other than Kim making the proposal, you'd hear me pondering the take-off velocity of aerodynamically contoured porkers. As is, who knows?

It was pointed out to me earlier today that SAML's own Security Services TC might be considered guilty of the same over-reaching.

In the same spirit of fairness, I propose that we change its name to the 'Security (not to say that there aren't other equally valid mechanisms) Services TC.

Cor blimey

What would translating Facebook into UK English consist of? A liberal sprinkling of 'effin idjits' around the UI?

I'm more a cat person

At the time, I questioned the wisdom of friending up with Dale on Facebook.

I probably wouldn't have if his invite message weren't so pathetic - going on about the identity community, solidarity, etc blah blah blah.

I'm happy to report that the investment paid off. It was through Dale that I've been able to connect with a far more valuable social hub.

All that remains is a little bit of social house-keeping removing some clutter.

Razor sharp

William of Occam was a 14th century English philosopher, best know for his 'principle of parsimony' in comparing different explanations for some phenomena.

entia non sunt multiplicanda praeter necessitatem

When translated and applied to identity, it's clear that Kim's Law 3 was preempted by some 700 years

entities must not be multiplied beyond necessity

Doggone it

Q: How is Sarah Palin like a proponent of old school user-centrism?
A: Notwithstanding their practitioner friends, they both see the 'back-channel' as a sinful 'choice'.

You betcha

Q: How is Sarah Palin like a password-based IDP/OP?
A: Because neither of them give you any assurance that they know what they are talking about.

Another angle on OAuth & ID-WSF

A comment from Robert on my doc contrasting the OAuth and ID-WSF authorization models made me think about another way to show their different scope and focus.

Below is a 'typical' ID-WSF flow, with those pieces that OAuth focuses on hilited in grey

As Robert points out, in ID-WSF the identity requestor (the WSC) first 'tries their luck' with an 'unauthorized request' to the identity attribute provider (the WSP). If this request is denied because of the alck of user consent, it's then that the WSP and the WSC engage in an interaction dance in order to get that consent - this set of messages logically identical to the OAuth flow.

OAuth would point to XRDS as providing the discovery component, but it 's not clear to me how to reconcile OAuth's existing static trust model with the possibility of real-time discovery? George?

Dogfood

I had uploaded a doc looking at OAuth & ID-WSF to Google Docs.

I wanted to publish the doc in this blog.

Google's UI

So, the very authentication model that OAuth & ID-WSF are designed to deprecate (i.e. a Consumer asking for User credentials at a Service Provider) is used to push a document that compares the two from Docs to Blogger (before you say anything about both being Google properties, it would work the same way for other blogging platforms).

Didn't work anyways.

Comparing OAuth & ID-WSF Authz Models

A first stab at looking at how OAuth and Liberty ID-WSF support user consent, requestor authorization, and subsequent access of protected identity resources

Corrections welcome

Comparing OAuth & ID-WSF Authz Models

I hear you brother

Andre preaches on the importance of quality, and the dangers of fast and easy compromises.

Although I don't bear the responsibilities and decision-making burden of a CEO (i.e. whether to get a DJ or a magician for the Ping XMas party, blue or green tinted drinks etc), Andre's words did strike a chord for me as an occasional specification writer.

There have been many a time when I felt a specification I was working on could be justifiably called complete, and so get it off my editorial plate.  The temptation to finish is strong.

So when ever I feel tempted to quit before the job is done, I think about those spec writers who've come before me.

Did the authors of RFC2119 stop at MUST & SHOULD? I'm sure we could have got by with just those two. But no, 'getting by' wasn't good enough for Bradner et al - they went the extra mile and added MAY as well. And then they added the 'NOTs' as well. That's giving 110%.

As another example, when drafting their charter, did the founders of the WS-Federation TC take the easy path of excluding key input? OK, well bad example.

OAuth UI Guidelines

Interesting guidelines from Google.

I would suggest however that recent events might cause people to question using a Google library as the gold standard for interoperability testing

Valdiating your OAuth implementation
Because OAuth is a recent standard, your company might also be looking for ways to validate that your implementation properly follows the OAuth standard.  One way to do that is to use the OAuth Proxy in iGoogle. 

You don't bring me flowers ..... anymore

As I recollect, we pretty much skipped past romance and jumped right to Stage 2.

Field Trip

There will be an unconference for the Identity Commons Working Group Kids Online following the next IIW.

Kids are welcome.

Yeah right. The last thing I want my Grade 1 girl to know is that Daddy's 'work' consists of sitting around in circles and using markers to draw on walls.

She'd want me to pay her for going to school.

Manual Social Portability

I've decided to drop Plaxo - the constant beating of my 'pulse' grew too much too take.

Consequently, I'm endeavouring to recreate on Facebook those social connections that had been unique to Plaxo.

Pray for me

If Mccain/Palin win, I expect there will be a backlash against liberal leaning blogs (that occasionally mock 'Intelligent Design' and other fairy tales) such as Connectid.

I predict a concerted campaign of low readership, poor Adsense revenue, and general disinterest. Not very nice but that's just how people like them operate.

Well I'm not hanging around waiting for that to happen. I'm moving to Canada. Oh wait, that's right ....

To my US friends, if the Rapture should happen, please know that I'll be laughing with you, and not at you.

New word

Main entry: im-dang
Pronunciation: \ˈim-ˌdang\
Function:

noun

: the barely audible tone heard on a conference call when you IM a fellow participant