I have to admit this is interesting is that the trust router would provide the ability for an RP to do this. I had managed to insert a different entity into the picture and wonder if I am wrong or of the document is just written odd.
I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? Jim From: [email protected] [mailto:[email protected]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Saturday, December 17, 2011 9:02 AM To: [email protected] Subject: [abfab] Issue 23 - Clarifications and typos Hi Jim, In issue #23 <http://trac.tools.ietf.org/wg/abfab/trac/ticket/23> http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write: " 1. The rules determinaion in pagraph <http://trac.tools.ietf.org/wg/abfab/trac/ticket/2> #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph <http://trac.tools.ietf.org/wg/abfab/trac/ticket/1> #1 2. Paragraph <http://trac.tools.ietf.org/wg/abfab/trac/ticket/3> #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations. " The current version of the document uses the term "Rules determination" as a way to indicate that the RP has to make a decision of where to route the AAA mechanism. This term is confusing. I agree with you that the writeup is a bit short with regard to what are the decision criteria. In fact, there is a separate document (which is not yet a working group item) that discusses these aspects in much more detail, see <http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 I suggest to reference that document. I agree that the LoA may have an impact on the routing, particularly when it comes to the broader question of assessing the operational security of some of the providers. Here is paragraph #3: Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IDP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the principal to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example in some federations intermediates validate information that is being communicated within the federation. I agree with you that the writeup is confusing. I believe it needs to take some of the work we did afterwards, such as with the document I mentioned above, into consideration. Ciao Hannes
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
