...
| Number | Line / Reference | Proposed Change or Query | Proposer | Resolution |
|---|---|---|---|---|
| 1 | N/A | The PDF appears to lack line numbers, so that may complicate the feedback here. | Fixed Scott Cantor - my bad, sorry (NH). | Resolved |
| 2 | L99, End of pg 4 | Nit, suggest you s/SAML 1.0/SAML 1.0 and 1.1 for completeness. | ||
| 3 | L113, Page 5 | Nit, s/intent/intend | ||
| 4 | Footnote 15 | Nit, s/subjected/subject | ||
| 5 | Line 169 | I think the "spirit" of pairwise IDs in SAML would make it improper to just forward them into the Internet as an OIDC claim. They were always intended by the original Liberty work as "secret" in some sense and not to be shared gratuitiously, so I think turning a pairwise ID into a non-pairwise ID through a proxy is not really appropriate unless the proxy is "inward" facing. I don't think the document is presuming that though. If the intent here is rather that the proxy be stateful and do a mapping from the inbound SAML value to an outbound pub claim, that isn't coming across as clearly as perhaps intended. It may be a similar question in the opposite direction but I don't claim to speak for the "intent" behind the pairwise nature of the sub claim in OIDC, whereas I can speak for what the intent was in SAML. | ||
| 6 | Line 211 | Nit, s/taking/taken | ||
| 7 | Line 337 | Those are not in any sense "SAML Attribute names" as used by our community so I would suggest the mapping be limited to eduPerson/etc. and OIDC and leave the SAML part out of it. Essentially if you can deduce that a SAML Attribute corresponds to a given LDAP/X.500 Attribute Type, then your mapping can transit that hop and leave the SAML part implied. I disagree with string-based attribute names in a pretty deep way but if you're going to do that, I would just leave the non-string naming in SAML off to the side. | ||
| 9 | footnote 15, P7 | Nit, s/the the/the | ||
| 10 | L34, P1 | Define Research and Education - s/R&E/Research and Education (R&E)/ | ||
| 11 | L35, P2 | s/R&S/Research and Scholarship (R&S) (then remove eventual definition bracket mention from L435, P21) | ||
| 12 | L103, P5 | s/. Reasoning is that/ because/ | ||
| 13 | Section 8 | Please also include voPerson attributes, which I believe can be mapped just like eduPerson attributes. | James Alan Basney | |
| 14 | L277 | 'In addition it is discouraged to base preferred_username on a SAML attribute.' Can a small explanation be provided? Is it just discouraged to based it on an eduPerson attribute? | Patrick Radtke | |
| 15 | L279-L302 | I'm unsure if these rules to determine email_verified would work across all schools. Specifically, a previous university employer of mine asserted for mail whatever the user entered in their profile, even if it was the email address of another user at the university. The IdP certainly wasn't asserting an email that has been verified to be in control of the end user, or validated in anyway. I'm not sure if this case is an anomaly or widespread, but since email_verified is not a required claim why guess at it's value? Or if you need to guess then perhaps if mail == eppn (which is quite common) and the eppn scope check is valid then assert true? otherwise you don't really know the institutional rules for how email addresses are picked, or what assumptions a downstream RP is making about email address and matching to existing accounts by email address and what security holes can occur. | Patrick Radtke | |
| As part of the consultation a face to face session was held at Internet2 TechEx 2018 ACamp on Oct. 19, 2018. Notes from this meeting can be found here: https://docs.google.com/document/d/1cGuVn3k0-IJ3BzSvACm1gCk_MMftYyTKRxvwpqfpStI/edit | Niels, on behalf of ACamp participants |
...