Hi Gabriel, Thank you for your comments. First, everyone please remember that this draft is absolutely a work in progress and meant to reflect what we are in fact standardizing, as well as indicate what we are not. Perhaps it also serves as an excellent way to focus us on what we may need to standardize but have not yet agreed to do so.
As to your comments: On 1/21/11 10:13 AM, Gabriel López wrote: > El 20/01/11 00:36, Jim Schaad escribió: >> >> I am in favor of having some diagrams really early in the processes. I >> think this really helps to get understanding setup early. But I tend >> to be >> a very pictorial person. >> > I agree with Jim here, flow diagrams will help to understand the > architecture and to detect missing problems. I agree, but I'm not sure that was what Jim was actually saying. Jim, were you asking for additional pictoral-non-flow-based diagrams? If so, what would you find useful? > > > some other comments: > > - pag. 6. - 5. [... ]At this stage, the RP will likely have no > idea who the principal > is. > > You propose here to optionally send a SAML Attribute Query to the > idP/AA, but this query has to include the user's subject. How does it > match with the previous sentence? At that point we are not yet ready to issue a SAML Attribute Query. That should happen in Step 10. As you can see there is some XXX in there that needs to be completed. > > You could also here request a SAML AuthnStatement that could be > use latter to request attributes by SOAP channels (if you decide to > consider this scenario) > > - pag. 6 - 6. IdP informs the principal of which EAP method to use > [...] > > In this case the RADIUS server plays the role of idP, but what > happens if the organization already have a running idP (i.e. Shibboleth)? They get to run some additional code. Not sure how we get around that. > > - pag. 7 - 9. What kind of checks is done here? could you provide > an example? I mean. > Are you checking if idP could issue an attribute > statement including user's attributes for SP? > An Attribute Release Policy? That is view of what Step 9 is all about. What would follow Step 9 (latter part of Step 10) would be a SAML assertion. Step 10 probably needs to be broken down. > > - pag. 12. if you decide to apply abfab arch over eduroam you > could make use of trust-anchor and PKI services (eduGAIN) to assert > trust between organizations, but this option is not described in the > draft. Thus far we have not ventured into PKI at all in the draft. > > - pag. 19. The text: "Host-based service names do not work ideally > when different instances > of a service are running on different ports. Also, these do not work > ideally when SRV record or other insecure referrals are used." is > not in-line with the rest of the section. Again, thanks for your comments! _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
