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