Relying party tailors assertion in browser artifact profile

[Tim Moses <tim.moses@entrust.com>]

Title: Relying party tailors assertion in browser artifact profile

Colleagues - Here are the two earlier messages that brought this requirement to light.

From myself ...

http://lists.oasis-open.org/archives/security-services/200108/msg00038.html

From Simon ...

http://lists.oasis-open.org/archives/security-services/200109/msg00007.html

Those opposed to our accommodating this requirement say that it is nothing more than a refinement for improved efficiency, because, once the relying party has been given the first authentication assertion (that does not satisfy its needs) it can request another one that DOES satisfy its needs.  Therefore, we can safely leave a solution out of SAML v1.0.  If, with experience, we find that the responsiveness of SAML v1.0 in this respect is inadequate, then we can address the requirement in SAML v2.0.

Those in favour of our accommodating this requirement argue that, currently, there is an asymmetry; a relying party that uses an artifact does not have the same facilities available to it as the relying party that uses a subject name does (the former must make two requests, the latter need only make one request).  There is also a privacy-related argument, in that, as the first authentication assertion is unsuitable to the relying party, more information than is necessary has been revealed about the subject.

Additionally, it is argued that the problem is simple to fix.  Simon makes one proposal in the message referenced above.  Here is another possibility ...

Where the schema for the query protocol currently says ...

<element name="Request" type="samlp:RequestType"/>
 <complexType name="RequestType">
  <complexContent>
   <extension base="samlp:RequestAbstractType">
    <choice>
     <element ref="samlp:AbstractQuery"/>
     <element ref="saml:AssertionID" maxOccurs="unbounded"/>
     <element ref="samlp:AssertionArtifact"/>
    </choice>
   </extension>
  </complexContent>
 </complexType>

Replace it with this ...

<element name="Request" type="samlp:RequestType"/>
 <complexType name="RequestType">
  <complexContent>
   <extension base="samlp:RequestAbstractType">
    <sequence>
     <element ref="samlp:" AbstractQuery minOccurs="0"/>
     <element ref="saml:AssertionID" minOccurs="0" maxOccurs="unbounded"/>
     <element ref="samlp:AssertionArtifact" minOccurs="0"/>
    </sequence>
   </extension>
  </complexContent>
 </complexType>

Then the request may contain both an AbstractQuery element AND an AssertionID element.

I don't' really expect this suggestion to stand up to scrutiny: the purists will complain that it leaves too much "unspoken".  I include it merely to indicate that the impact on the schema may be negligible.  Personally, I don't believe the impact on an implementation will be significant, either.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183