El 21/01/11 10:53, Eliot Lear escribió:
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.
so, the idp returns SAML attributes without a SAML attribute query or
the RP, in a latter second round-trip sends the SAML attribute query to
the idP over RADIUS.
That's one of the issues the diagrams should clarify :)
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.
and the trust based on the AAA infrastructure could not be enough.
thanks for the answer.
regards, Gabi.
- 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!
--
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email protected]
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
