Potential errata on AuthnContextDeclRef/ClassRef

Hi folks – it’s been awhile… yes… I’m still lurking out here

J

 

And gee – the committee is getting two questions related to 
authn contexts in 2 days… that must be a record 
J

 

I was asked a question today about whether it was valid to specific one of the URN’s we defined for the SAML-defined
authn context classes inside an <AuthnContextDeclRef> element? 

 

I responded that I thought that was improper since I believed it was intended that those URN’s were to be used in conjunction with an <AuthnContextClassRef>, not a
DeclRef. But when I went back and reread the relevant spec sections, it doesn’t appear to me that we specifically disallowed it. 
Both the ClassRef and the 
DeclRef use the xs:anyURI 
datatype, so obviously URN’s would be allowed in either one. 
So I was looking for normative text that constrained the usage. AFAICT, we didn’t come out and specifically say that if you’re using one of the predefined classes, it’s URN MUST be specified using the <AuthnContextClassRef>
 and not using the <AuthnContextDeclRef>. 
The language in the core spec and section 3.0 of the 
authn context spec seems to infer this, but doesn’t say it specifically.

 

My memory is a bit fuzzy, but I believe the intention of the committee was as I described. 
If so, then the suggestion is that we re-examine the wording in the 
authn context and core specs and make it a bit clearer. 
If the constraint is already in the spec and I missed it, can someone point me at it? 
Or if it there was a specific reason for allowing their use in a 
DeclRef, could someone explain what it is? 
If they were allowed there, then I guess I don’t understand why we defined the <AuthnContextClassRef> in the first place.

 

Thanks,

 

Rob Philpott
| Senior Technologist | RSA, the Security Division of EMC

eMail:
 | Office: 781.515.7115 | Mobile: 617.510.0893