[abfab] Comments on draft-ietf-abfab-aaa-saml-05

["Jim Schaad" <[e-mail]>]

Josh and Sam,

This looks much more like the discussion that we had after the last IETF
meeting so I am generally happy.

1.   I think inserting a paragraph start at "The name identifier..." will
make it clearer which artifacts are designed to be used in ABFAB scenarios
and which are designed for more universal usage.

2.  In section 2  for the last bullet point in the first list - should this
be the subject of an assertion or the subject of a protocol message?  I am
always very unclear about SAML naming of items.  However this confirmation
method can be in both a SAML assertion and in a query (i.e. AttributeQuery).

3. In section 5.2 - I am not happy with the single reference to RADSEC as
being the required.  I would be more happy if the profile required either
TLS/UDP or TLS/TCP as required.  Either that or TLS/TCP should be
recommended.  I am worried that without this there might be an issue with
people thinking it is restricted to UDP.

Note that for longer messages you probably really want to require the
TLS/TCP version not the DTLS/UDP version.

4.  In section 5.2 - I have probably said this before, I am not really a big
fan of the use of language such as "MAY transmit a SAML request".  If you
don't do the request how can one say that you are acting as a SAML
requester.  A similar statement is also made for the second item.  Just say
"returns a  SAML protocol message" and then talk about reasons that you
might not wish to do so.

5.  In section 5.2 - s/responder MAY also return/responder MAY return/ - it
might be read as saying you could return two even though that is explicitly
forbidden.

6.  In section 5.2 - I think we should probably add the following paragraph:

SAML responders SHOULD return a RADIUS state attribute as part of the
Access-Accept message so that future SAML queries can be run against the
same context of an authentication exchange.

7.  In section 6 - update the reference for NAI to draft-ietf-radext-nai

8.  In section 7.3.3 - I am not sure that the dependence on the abfab
document at the end of the section makes sense.  For example, why should the
EAP method support channel binding in order to return a SAML response?  I
think that one can restrict the requirements to those in the AuthnRequest
and those necessitated by the application (whatever the application).  You
probably just missed this in the general ABFAB removal.

9.  In section 7.4.1 - I think the second paragraph can be removed and
placed in section 7.4.2.  It is not related to the AuthnRequest but to the
Response.

10.  In section 7.4.2 - I think we might need to make a statement about
returning no subject identifier and the correct interaction with the
AllowCreate attribute.  If the IdP is not going to return a name, but is
just returning a subject conformation that says - the user associated with
this conversation - is this to be considered a "new identity" for the user?

11.  In section 7.4.2 - I have a problem with the last bullet point.  I
would be happier if the text looked more like:

Other conditions MAY be included as requested by the Relying Party or at the
discretion of the Identity Provider.  The Identity Provider is not obligated
to honor the requested set of conditions in the <samlp:AuthnRequest>, if
any.  If the Identity Provider does not honor the requested set of
conditions is MUST either not return a <samlp:Response> message or return a
<samlp:Response> message with an error.

12.  In section 9.  I think in this case it would be useful to have an
informational reference to TEAP about mapping these from an EAP method to
the URIs specified.


s/artefacts/artifacts/