Ok - let's try this again - only without the big mistake from last time. 1. Republish the document even if it has no changes so it can be found on the working group page.
2. SAML attributes are named by a naming type and a name value, but they may also be thought of as being named by the issuing authority. In the event a urn such as urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used, then the meaning is (hopefully) well understood and common to all authorizes. However if a string such as "Major" is used, the meaning and set of values may be highly dependent on the issuing authority. 3. Traveling all the way back to Beijing, I believe it was stated that we would only ever have a single SAML assertion that is transported from the IDP to the service, however it could contain nested statements. Is this still a working assumption for the group. Note: I do not believe that this has ever been explicitly stated in any documents. What happens if AAA transports back two different SAML statements? 4. For SAML attributes - What happens if there are multiple values for a single attribute. These could be multiple values within a single SAML assertion (i.e. two different <Attribute> clauses with the same name but with different values such as two different email names (which would be required to be transported as two different attributes). Or they could be given by two different SAML statement issuers, but the items are nested. In this case the values could be either the same or different, but the issuer name for the attribute would be different. In this case should they be treated as alternate values for a single attribute or as different attributes which are scoped by the issuer name. 5. Are we defining a property in the GSS EAP namespace that can contain the set of attributes that the service wants to have returned by the IDP? This could take the value of the SAML Request to be sent to the IDP. 6. I don't understand how an independent check could be made on any SAML assertions without pulling out the total SAML assertion, checking it and then pulling the attributes from it. How could one check the value of a single attribute (per last sentence of section 5.2 para 2 - An implementation MAY apply local policy checks to this assertion and discard it if it is unacceptable according to these checks.) 7. I am not sure what section 5.3 is saying - Is this just a to be written place holder? 8. We are establishing a new registry in this document. What are the rules we are going to define for this. I assume we want expert review but I don't remember there ever being a discussion. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
