>>>>> "Gabriel" == Gabriel López <[email protected]> writes:
Gabriel> 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.
Gabriel> so, the idp returns SAML attributes without a SAML
Gabriel> attribute query or the RP, in a latter second round-trip
Gabriel> sends the SAML attribute query to the idP over RADIUS.
Gabriel> That's one of the issues the diagrams should clarify :)
I'd like to push back on this a bit.
If there's one thing coming out of the attribute provider discussion it
is a strong indication of complexity. Let's have the basic abfab
architecture not include support for multiple round trip attribute
queries. No one has stepped forward to do the work. The current code,
GSS EAP spec, GSS naming extensions and semantics of the SAML attributes
all need to be extended.
I think Josh has volunteered to do some of the work of extending the AAA
attribute semantics.
I think that Eliot had volunteered to take a stab at writing up some of
the architectural issues with the attribute query problem to show that
it is something we can do as a future extension. I think there's plenty
of text in the list discussion to support that.
However, this feature is detachable from the base architecture.
Let's detach it: the base architecture is complex enough.
What would this mean? It would mean we would not discuss additional
AAA-based attribute queries in the diagrams or the step-by-step
overview. We would have a brief discussion of the issues in their own
section, but would not enumerate the interactions in the rest of the
document. We will not make it a requirement that components of the
system designed today support these queries. We will continue to make
sure that what we build can be extended in the future to support
multiple rounds.
When someone steps forward, they can write documents extending our
system to support this feature. Probably at least one of the documents
needs to fall into kitten not here.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
