: 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.

Wednesday, October 29, 2008

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.

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).

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.

Thursday, October 23, 2008

Wednesday, October 22, 2008

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 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.

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 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?

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.

Thursday, October 16, 2008

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.

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.

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.

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).

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.

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.

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.

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.

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.

Monday, October 13, 2008

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).

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

Thursday, October 09, 2008

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.

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:

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.

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.

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

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).

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?

Thursday, October 02, 2008

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).

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.

Wednesday, October 01, 2008

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.