>, however it means that there is a question >on how an Acceptor could later ask for additional attributes from the IdP. >While this is not currently supported by GSS-EAP (yuk), I don't know that >I >also want to update this document to be able to do it here. I don't know >that that is going to be in the Access-Accept/Reject. However it may be >that is a different set of bindings and should be addressed separately. >Given the current GSS-EAP, this is an explicit requirement that needs to >be >stated. (OK - so I am arguing both sides of the issue).
Recall that this text is describing the general case, where the SAML requester is not necessarily an ABFAB acceptor; it could be wireless AP or VPN concentrator and their existing RADIUS API is probably good enough. However that's definitely not true in the case of an ABFAB acceptor; we are dependent on the GSS API and so we also need a discussion in Kitten. For the purposes of this document, I had been assuming that we could safely decouple discussion of the abstract assertion request API (in Kitten) from discussion of the protocol (in ABFAB), and that we should define the latter first in order to motivate the necessary work in Kitten. We may need to reconsider things if that is not a reasonable assumption... >> >8. In section 5.4.1 paragraph 3 - I am not sure how this section >> >interacts with the ability of an IdP to return a Pseudonymous >> >identifier. Are you stating that the identifier must already exist, or >> >just that the policy for creating the identifier must already exist in >> >the case AllowCreate is set to "false". >> >> The former. However, isn't this policy orthogonal to the question of >whether >> the identifier is pseudonymous or not? > >Yes, it is orthogonal to the question is the identifier pseudonymous. >Changing the text slightly might solve my issue. The problem I have with >"establishing a new identifier for a principal if none exists". The >question is, is a new pseudonymous tag for an existing principal >"establishing a new identifier". Yes, for the particular identifier that denotes the subject of an assertion (which, confusingly, may or may not be the "tag" used by the application to denote the subject; often an attribute (e.g., 'mail') from the assertion is used instead). Do you have a specific concern? >> >> >9. In section 5.4.1 last paragraph - I think we should make some type >> >of statement about what happens if either the request is not signed, or >> >the signature on the request cannot be validated by the IdP. I think >> >that both of these cases are going to be more likely that the case of >> >it is signed and the IdP happens to be able to validate the signature. >> >> I agree. I would prefer that the spec says words to the effect of "die >>if >the >> signature, if any, does not conform to policy" and remain silent on the >> question of policy. >> >> (I have a strong personal preference to deal with this question by >prohibiting >> message-level signatures altogether, and leaving integrity to the >transport >> level where deployers have a better record of getting this right, but >>that >> wasn't a popular opinion in Taiwan). >> > >I am in the same camp that you are and did not understand the ground swell >in Taiwan. Yes, I am now kicking myself for not digging my heels in. As I won't be in Atlanta I will separately write mail arguing that the WG reconsiders this. >> >10. I believe that a discussion of what is expected to happen as these >> >messages cross federation boundaries is probably in order. >> >> What would you expect to see in this discussion? > >My problems deal with the questions dealing with if names of attributes >should be changed/could be changed as federation boundaries are crossed. >The values could also be remapped at the same time if different >federations >had different ideas of things. Values could be silently removed if the >second federation does not believe that the first federation has the >ability >to make such a statement, and this will make it appear as if the IdP was >unwilling to provide the information. See the discussion from Paris in >the >audio. This is about the application of policy, and so I would prefer if we punted this discussion to the architecture document. Would this be ok? Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
