Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt

[Stefan Paetow <[e-mail]>]

>> with the submission of the updated version of the aaa-saml
>> (draft-ietf-abfab-aaa-saml-10), we consider the document is now ready
>> for a Last Call.
[...]
> Hmm, I'd feel more comfortable if we'd had one or two reviewers...

Hi, 

I read through the draft and have a couple of nits that you're welcome to tell me to go away with:

- Introduction:

The introduction contains two bulleted lists. The first terminates each bullet with a fullstop. The second doesn't. Elsewhere in the document, other bulleted lists follow the format of the first. For consistency, the second list in the introduction should follow the same format:

   o  A URI that uniquely identifies the protocol binding or profile.

   o  Postal or electronic contact information for the author.

   o  A reference to previously defined bindings or profiles that the
      new binding updates or obsoletes.

   o  In the case of a profile, any SAML confirmation method identifiers
      defined and/or utilized by the profile.

- Section 4.3.2:

A fullstop is missing after the <entityId> in the first paragraph. It should be:

   Identity Providers MAY apply policy based on the Relying Party's SAML
   <entityId>. In such cases, at least one of the following methods is
   required in order to establish a relation between the SAML name and
   the AAA name of the Relying Party:

- Section 4.3.4:

A missing comma in the last sentence of this section. It should be:

   [...] RADIUS configuration is used to provide policy, including
   which attributes are accepted from a Relying Party and which
   attributes are sent by an Identity Provider.

- Section 6.2: 

A missing comma in the first sentence of this section. It should be:

   To implement this scenario, a profile of the SAML Authentication
   Request protocol is used in conjunction with the SAML RADIUS binding
   defined in Section 4.

- Section 9:

The first sentence refers to a 'Relaying Party', while the remainder of this section refers to a 'Relying Party'. I can only assume that 'Relaying' should actually be 'Relying'. Corrected text:

   The profiles defined in this document allow a Relying Party to
   request specific information about the Client, and allow an IdP to
   disclose information about that Client. [...]

>   o  Assume that the Client's identifier implied by a SAML <Subject>
>         element, if present, takes precedence over an identifier
>         implied
>               by the RADIUS User-Name attribute.
> 
> 
> *what*?!  This flies in the face of 4.3.1.

Does 4.3.1 refer to the outer identity of a request (I assume so)? AFAIK, 4.3.1 refers only to the NAI realm (the RP doesn't have access to the full identity). 6.4.2 specifies that if the IdP issues an assertion, the assertion's <Subject> may refer to the actual user (I assume that's the inner?), in which case, 6.4.3 makes sense where the <Subject>, if it exists, overrides whatever was in the original request's User-Name attribute? Or am I mixing things up? Just a question... :-)

Stefan Paetow
Moonshot Industry & Research Liaison Coordinator

t: [phone]
gpg: 0x3FCE5142
xmpp: [e-mail]
skype: stefan.paetow.janet
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk
 
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.