>> 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: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: [email protected]
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
