OpenID's Assertion Quality Extension

Today, David Recordon announced the release of the first draft of the OpenID Assertion Quality Extension. This specification is directed at solving the question of "how did the user authenticate" both when they created their account and now for this particular authentication session.

Overall, as far as I can tell, there is nothing in this specification that is not easily handled using the SAML Authentication Context structure and so I don't understand why they didn't just adopt that model as-is (and the SAML model clearly handles much more than the limited cases supported currently by this proposal). At the minimum, this document should be a limited profile of what portions of the SAML model they want to use.

I also have some more specific feedback about things in the specification:

• Section 4: Relation to SAML Authentication Context) contains the following:
  

  The Security Assertion Markup Language (SAML) Authentication Context ([SAMLAC] (Kemp, J., “SAML 2.0 Authentication Context,” 2005.) defines mechanisms by which SAML Service Providers and OpenID Providers can discuss the context of an authentication assertion.

  The authors acknowledge the similar motivation between SAML's Authentication Context and this extension. Where possible, we have attempted to stay aligned with the SAML Authentication Context model. Indeed, we see this topic as a likely area of convergence between OpenID and SAML. More work is needed here.

  This is all you hear from or about SAML in the entire specification. There are no other references to the SAML authentication context, nor any use of the structures or capabilities of the Authentication Context. I'm not sure why this is even mentioned here if they aren't going to make use of any of the SAML work in this area.

• Section 5.1 ("Enrollment Properties") talks of 3 of the possible enrollment properties (captcha, email and telephone verification).
  • I don't think captcha belongs in the same list, as it's just a basic way to make it harder (but not impossible) to automate the login process by another computer) but that isn't my call.
  • I think that these enrollment properties require a date to make them useful (as in the verification was done 10 years ago or it was done yesterday). The point being that a verification done a long time ago has little value today.
  • I think the model should be more generalized to allow other verification tokens to be added without having to rev the specification again. One possible way would be for each enrollment to have two properties: a name and a value.
  • I would recommend changing "Did the OP present the End User with a CAPTCHA during the account creation process" to "Did the user complete a CAPTCHA prompt successfully during the account creation process".
• Section 5.2 Supported Authentication Properties:
  
  • There's no definition of what the listed methods actually mean. Does a password mean that it was at least 3 characters long or are blanks allowed? Does a pin mean that it's an all-numeric password (so why is it different from a password), does a fingerbio mean that a fingerprint was validated (to what level of accuracy)?.

    I suggest that there be at least some clear definition of exactly what these mean (minimally).

• Section 6.1 Request Parameters
  
  • I think that the RP should be able to specify desired enrollment properties rather than having to just get back data that it can't use in the response (in other words if the RP requires that email address be confirmed, getting back an authentication response that says it wasn't confirmed is pretty useless).
  • I think they should consider using authn as a shortcut for authentication rather than auth. It gets very confusion when you eventually also start talking about authorization.
  • I think the language around what to do when multiple auth_modes are specified is confusing and makes it hard for the RP to get exactly what they want. In Liberty (and then SAML) we took the view that the RP would typically give an exact OR'd list (so any in the list are valid) or would say something along the lines of "this or better" - meaning that they didn't care too much about the specific method as long as it was at least as "strong" as the specified method). I would suggest OpenID follow a similar model as it makes it much simpler for the RP.

• Section 6.2 Response Parameters
  
  • I'm confused by the "comma-delimited list" of methods in openid.aqe.auth_mode while the paragraph after the bullets says that if more than one method was used you must post-fix the auth_mode and auth_age with sequenced numbers (1, 2, etc.).
  • For auth_age, it probably should be 'The number of seconds prior to this response' rather than request.
  • As I stated previously, enrollment_verified values should have an age and should be extensible.
• Section 9 Examples
  

  It would be good to include some example authentication requests and responses here to show how the messages flow.

Again, I reiterate my earlier statement: Why not just use SAML Authentication Context. Lots of thought, energy and analysis went into this once already and as long as it isn't falling short of your needs, it would seem much simpler for everyone to adopt it.

Tags : identity / openid / sso / saml / liberty / liberty alliance / aqe / authentication