RE: [egov-ms] Groups - eGov Work Plan 2008-9 (eGMSWorkPlan2008-9.doc) uploaded

[<Colin.Wallis@ssc.govt.nz>]

Thanks Giles

 

That's clarifies my misunderstandings but I have commented inline below.. 

 

  My feeling is that what needs to be standardized is :

1.       the way of binding SAML assertions to Authentication Levels – and then people will point to whichever policy they feel most comfortable with. I.e. a de facto standard may emerge.

<<CW: If I understand your comment correctly, I'd say that the de facto standard already exists in NIST 800-63 that does this, and is now deployed globally>>.

 

**This is true to a certain extent, but in Europe, it is certainly not true. We have a plethora of different models, as you can see in the IDABC country reports (on the page I sent earlier). 

<<CW: Yes, I am aware, and so assuming 100% convergence is not possible, even if there was a CEN or similar 'uber' jurisdictional standard that most member states could agree on, then a model and mapping would be very useful>>   

  

2.       However, a well-structured, human readable model of authentication mechanisms which can be mapped to NIST, EU (IDABC), NZ etc... models might also be useful. SAML Authentication Context doesn’t fulfil that role at the moment because it’s only defined by an XML schema with no human-readable content at all.

<<CW: Hmm,I accept your point about the modelling, but XML is human readable isn't it? OK, OK, not everyone's favourite read, but look at this excerpt from NZ's own authentication messaging spec (the GLS stands for the Government Logon Service). 

**

1.      Even as XML, Authentication-Context is not a well defined standard. There is NO documentation for any of the elements in the schema other than what you can find inside the actual XSD definition. Even that is not very complete.

2.      Even if there were documentation, a standardised model is useful at the level of human-readable policy – so an XML, machine-readable standard is not the right place for it. I don’t say that it wouldn’t be relatively easy to translate it into a human readable policy language.

3.      The SAML AC model is not able to express many aspects at least of the models we find in Europe (e.g. use of qualified signatures) – except by extension (i.e. it doesn’t define all the required semantics) 

 

 

<<CW: So I did misunderstand your comment re 'XML schema with no human readable content:" My apologies.

You are correct that the AC spec is mostly schema dealing with AuthnContextClassDeclarations ..x509, password protected transport, biometric tokens etc.  All this done by the editors before real use cases from deployers was available to inform them (and I think that's why there's not much content in there). The result is that much of AC is not supported by vendors, because deployers like us don't need it (at least right now), whereas we do need LOA etc and pragmatically have looked towards gone towards NIST.  But as you saw, we just put in our LOAs as a string.  What Eric/Liberty Alliance have done with the draft LOA doc to the OASIS SSTC is to create a generic schema to capture this (amongst other things).

 

So where does this leave us? I think it leaves us with a note of caution about adding human readable content to the existing AC.  By all means add that content (and schema) if it is backed up by real use cases, which then gives vendors the rationale to support it.   Otherwise everyone's efforts will be largely wasted.  You are much closer to the gap between current AC and the European models.. I think the SSTC would welcome your valuable 'use case backed' contributions to a spec which was, in effect, a strawman.>>