I have to both remember what I was thinking and find a copy of the document for review again.
> -----Original Message----- > From: Josh Howlett [mailto:[email protected]] > Sent: Monday, October 01, 2012 6:55 AM > To: Jim Schaad; Sam Hartman > Cc: [email protected] > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > Jim, > > First, I apologise for the appalling tardiness of this response to your review. > Thank you for your comments. > > >Major > > > >1. Do we have any other examples where we might have a SAML > >requester/responder other than the case of the RP/IdP? If so, it might > >be wise to mention at least one other case in the introductory > >paragraph in section 1. Otherwise it might be easier to just say that > >we are sending messages between the RP and the IdP and not generalize > >it. Can anybody see a reason that one might want to reverse the > >endpoints? So that the RP becomes the server and the IdP the client??? > > I agree that your proposed change would more clearly reflect the primary > motivating use case (Abfab), but I would strongly prefer to maintain the > generalisation because it maintains consistency with the other bindings > defined by OASIS SSTC. These bindings talk of requesters and responders, > and RPs and IdPs are instances of higher-level abstractions that happen to > use these bindings (as requesters and responders) to communicate. > > I would be happy to add some text talking around this point, if you think that > would help? Moving the first sentence of pargraph 4 into paragraph 1 would address my concern, that people don't read one paragraph - say this is abfab only - and skip. > >3. In section 4.1 and 5.1, the Identification will require an IANA > >action. > >I think we are looking at urn:ietf:params:xml:ns:abfab:<something goes > >here> > >I think that something probably looks like SAML:binding:RADIUS-binding > >in section 4.1. The contact information should be [email protected]. > > Ok. > > > I don't see > >any requirement that the binding should be specific to the RADIUS > >transport > >- do you? > > Well... I think it has to, by definition. The underlying transport is inherent to a > discussion of any binding. Perhaps I have misunderstood your point? > I think that this issue had to do with confusion on my part on the differences between what happens for RADIUS and Diameter. I agree with you that this is a RADIUS specific transport now, and "RADIUS" can be transported by Diameter. > >4. In section 4.2 item #2 - If the SAML responder is going to response > >to a SAML request, is there a requirement that the responder MUST > >response no later than the Access-Accept or Access-Reject message? > > I think that's implicitly true, because either of those messages necessarily > concludes a RADIUS exchange. However, I like the idea of making this explicit > in the text. > This currently feels good to me, 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). > > Also what other > >currently defined packets is the element permitted in - for example can > >I include it in an Access-Challenge packet? > > I have a strong preference to constrain the SAML response to the Access- > Accept and Access-Reject packets. RADIUS has a really fuzzy notion of a > session, and I think drawing some clear boundaries here could avoid > inadvertently reaching inconsistent states at the AAA and SAML layers. > > >5. In section 5.2 - Section on Responses: - I am confused when I read > >this text. It first says that you must return exactly one > >authentication statement. It then says that the IdP can return other > >statements in the assertion. Are these other assertions allowed to be > >authentication Statements > > No; only allowed one of these. > > > or are they some other type of statement? > > Yes. A SAML assertion can contain three types of statements: > authentication, authorisation and attribute. > Ok - I think was I needed more SAML background at the time. > >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". > > >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. > >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. > >4. Bad grammar /confirmation as the processing as defined in/ I don't > >know what this should be. > > Sorry -- defined where? Section 5.4.2 bullet point 4 (search for the string) > I will have an update out by the end of the week. > > Thanks, 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
