>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> 2. SAML attributes are named by a naming type and a name
Jim> value, but they may also be thought of as being named by the
Jim> issuing authority. In the event a urn such as
Jim> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used,
Jim> then the meaning is (hopefully) well understood and common to
Jim> all authorizes. However if a string such as "Major" is used,
Jim> the meaning and set of values may be highly dependent on the
Jim> issuing authority.
True.
Keep in mind that the name attribute is in the context of a name.
In the case of gss-eap, the realm in which the name is interpreted
should be reasonably obvious from the name.
For SAML EC, it may be a bit more tricky, but honestly, if you use a
non-globally-unique name attribute you may run into trouble.
Jim> 3. Traveling all the way back to Beijing, I believe it was
Jim> stated that we would only ever have a single SAML assertion
Jim> that is transported from the IDP to the service,
I don't remember that so much as saying that was what we are specifying
now.
Jim> however it
Jim> could contain nested statements. Is this still a working
Jim> assumption for the group. Note: I do not believe that this has
Jim> ever been explicitly stated in any documents. What happens if
Jim> AAA transports back two different SAML statements?
I'm confused: I thought an assertion was a kind of statement.
If we have multiple assertions, I would expect that
draft-ietf-gss-eap-naming would not really apply or would only apply to
the core-/main assertion.
I'd expect other assertions would typically have a different context.
Jim> 4. For SAML attributes - What happens if there are multiple
Jim> values for a single attribute. These could be multiple values
Jim> within a single SAML assertion (i.e. two different <Attribute>
Jim> clauses with the same name but with different values such as
Jim> two different email names (which would be required to be
Jim> transported as two different attributes). Or they could be
Jim> given by two different SAML statement issuers, but the items
Jim> are nested. In this case the values could be either the same
Jim> or different, but the issuer name for the attribute would be
Jim> different. In this case should they be treated as alternate
Jim> values for a single attribute or as different attributes which
Jim> are scoped by the issuer name.
GSS naming extensions does not really support this; I'd say the behavior
should be undefined until GSS has a story for this.
Jim> 5. Are we defining a property in the GSS EAP namespace that
Jim> can contain the set of attributes that the service wants to
Jim> have returned by the IDP? This could take the value of the
Jim> SAML Request to be sent to the IDP.
It's my understanding we are not currently doing that.
I'd prefer to have someone say that they would implement before we spend
energy specifying this.
Jim> 6. I don't understand how an independent check could be made
Jim> on any SAML assertions without pulling out the total SAML
Jim> assertion, checking it and then pulling the attributes from it.
Jim> How could one check the value of a single attribute (per last
Jim> sentence of section 5.2 para 2 - An implementation MAY apply
Jim> local policy checks to this assertion and discard it if it is
Jim> unacceptable according to these checks.)
Someone wants to log in as root.
Your local policy doesn't believe they should be authorized to do so.
Jim> 7. I am not sure what section 5.3 is saying - Is this just a
Jim> to be written place holder?
I think it's a TBD.
Jim> 8. We are establishing a new registry in this document. What
Jim> are the rules we are going to define for this. I assume we
Jim> want expert review but I don't remember there ever being a
Jim> discussion.
Are you talking about the URN registry?
If so, I'd assume ietf consensus or standards action.
It's just a URI registry; you shouldn't need ours unless you're
publishing our documents.
If you are on your own, use your own.
Jim> _______________________________________________ abfab mailing
Jim> list [email protected] https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
