Some comments from me. Mostly very minor nits, but some larger questions. Obviously I'm ignoring the bits which are obviously still to be done.
Overall - think it's looking pretty good, all made sense to me, and described the various components of ABFAB appropriately. But I already had a pretty good grasp of that so that view my not be independent enough. Stuff: Abstract, Para 1. "common building blocks in common" - lose the first "common". Sec 1, Para 3. s/signaling/signalling. Sec 1, Para 3, line 5 - s/protocol/protocols Sec 1.1 Para 4, line 3/4 - a bit informal! "This is due the fact that the terms used by the different standards we are picking up don't use the same terms". Perhaps "This is due to the fact that the different standards in use within the ABFAB architecture use differing, and sometimes incompatible, terminology". Sec 1.2 Para 8?, line 1 - "The nature of federation dictates that there is some form of relationship between the identity provider and the relying party". Not sure this is true at all. There are plenty of examples I can think of where there is no relationship between IdP and RP other than they're in the same federation, yet the subjects still make use of the service - e.g. community managed wikis or whatnot. Sec 1.2 Para 14?, - "that is only Requiems completing" - think something went horribly wrong here :-). Sec 1.2 Para 14? - "publishing a usage point" - what's "a usage point" in this context? I'm pretty sure I know what you mean, but many people may not be... Sec 1.4 Para 1 - "and its the" - think you need to lose a word here... Sec 1.4 Point 1 - should probably include a reference to the UI/Usability I-D which discusses this kind of thing. Sec 1.4 Point 3 - don't think "setups" is a word :-). "sets up". Sec 1.4 Point 4 - "to determine what IdP" - "to determine which IdP". Sec 1.4 Point 5 - you've used RP in all previous points, now you use "Relying Party". Suggest you use RP for consistency. Sec 1.4 Point 5 - "Once the RP knows who the IdP is, it (or its agent) will send a RADIUS/Diameter request to the IdP" - "Once the RP knows which IdP to use, it (or its agent) will send a RADIUS/Diameter request to it". Sec 1.4 Point 5 - "At this stage, the RP will likely have no idea who the client is." - Not sure what you mean by this? Sec 1.4 Point 5 - s/Request//Requests [SAML Attribute Requests] Sec 1.4 Point 7 - "between the EAP peer and the EAP server, i.e., the client and the IdP in our identity management terminology" - "between the EAP peer and EAP server (a.k.a. client and IdP) - (this is not "identity management" terminology). Sec 1.4 Point 7 - "If the IdP is unable to authenticate the client, the process concludes here." - ...and what happens as far as the user is concerned? Sec 1.4 Point 7 - "channel bindings" is introduced. Not sure if there should be a reference here? Not least because there are different kinds of channel bindings. Sec 1.4 Point 9 - s/what if any/which if any Sec 1.4 Point 11 - "If additional attributes are needed from the IdP the RP may make a new SAML Request to the IdP"... over AAA? or using a back channel SAML binding? Sec 1.5 2nd bullet point - s/Means/The means. Sec 1.5 2nd bullet point - do you mean "multiple authentication methods" as in multi factor authentication, as in agility of a single authentication mechanism, or both? Sec 1.5 3rd bullet point - "Hence, the architecture requires no sharing of long term private keys."... is not a design goal, or rather, this bullet isn't framed as a design goal but states a consequence. Either put in on the previous bullet point, or frame it as a design goal... Sec 1.5 4th bullet point - "large numbers" maybe should be quantified or bounded in some way. To some thousands is a large number. To others, billions... Sec 1.5 - "Despite the increased excitement for layering every protocol on top of HTTP there are still a number of protocols available that do not use HTTP-based transports". No nits at all. I just like this sentence a lot :-). Sec 1.6 Para 1 - "Interestingly, for network access authentication" - I'd suggest "Interestingly, for federated authentication in the network access context". Sec 1.6 Para 1 - "was quite successful" - "has been successful" Sec 1.6 Para 1 - s/EDUROAM/Eduroam. Sec 1.6 Para 2 - "By using" - "By reusing". Sec 1.6 1st bullet point - "It already needs a method of doing routing of requests" - "It already has a method of routing requests". Sec 2 Para 2 - "assumes updates to the relying party" - "assumes updates to the relying party to support ABFAB" or somesuch. Sec 2 Para 3 - s/ways for/ways of Sec 2 Para 3 - "the usage of the GSS-API was chosen." - "the usage of the GSS-API was chosen as many of these protocols already support GSS-API". Sec 2 Fig 1 - We've had discussion about what federations are, but "federation substrate"? Sec 2 para 1 - s/Part/Party Sec 2.1.1 para 1 - s/exist in RADIUS/exist in the RADIUS Sec 2.1.1 para 1 - s/reasonable/reasonably Sec 2.1.1 para 1 - "These protocols are nicely designed" - "Helpfully, these protocols are designed". Sec 2.1.1 para 2 - "We leave as a deployment decision, which protocol will be appropriate" - "We leave the choice of protocol to be used as a deployment decision". Sec 2.1.4 para 1 - "was an affirmative response from the IdP" - Bit vague. What do you mean by affirmative response? I know what you mean but the reader may not. Sec 2.1.4 para 2 - "for our work" - "to achieve our goals". Sec 2.1.4 para 2 - "It will be necessary to update IdPs" - need to be more specific here about which "IdP you're talking about - i.e. update the ABFAB IdP (some may read as meaning the SAML IdP). Sec 2.1.4 para 2 - "that need to return SAML assertions to IdPs" - don't you mean to RPs? Sec 2.1.4 para 4 - "provide origination" - "provide assurance as to the origin"? Sec 2.1.4 para 5 - "Attributes placed in SAML Assertions can have different namespaces assigned to the same name." - I think this sentence needs a bit more explanation for those not familiar with SAML. Sec 2.1.4 para 5 - s/cases a the/cases the Sec 2.1.4 para 5 - |In many, but not all, cases the federation agreements will determine what attributes can be used in a SAML statement." - not sure that's really the case. Federations typically determine a recommended set of common attributes, but "can be used in" doesn't quite describe that properly. Maybe something more like "will determine the semantics of a common set of attributes to be regularly used in a SAML statement"... Sec 2.1.4 para 5 - "into the onces" - "into the ones". Sec 2.1.4 para 5 - "If the proxies are modifying the SAML Assertion, then will obviously remove any signatures on the SAML Assertions as they would no longer validate." s/then will obviously/they should obviously" (note 2 changes - then->they and will->should) Sec 2.2 para 2 - refs to channel bindings docs please. Sec 2.2.1 para 1 - " In addition, use of browsers for authentication restricts the deployment of more secure forms of authentication beyond plaintext username and password known by the server." - Not true, you can do more than username/password authn in a browser... Sec 2.2.1 para 6 - "i.e,service" - "i.e., service" Sec 2.3.1 para 3 (line 4) - s/prospective/perspective Sec 3.3 para 2 (line 6) - s/suchs/such Sec 3.3, various bits - language needs to be tidied up, e.g. "ABFAB needs to adopt this approach.". Sec 4 - what about cases where the IdP doesn't know the attribute authority, but the user does? Sec 5 para 1 - "Sharing identity information raises privacy violations" - I think "Sharing identity information across organisational boundaries raises the possibility of privacy violations" is a bit more accurate. Sec 5 generally - You've gotten this far through the document without using the word "user", instead principal, subject, etc. Should carry on with that for consistency. Sec 5.2 para 1 - "This relationship will be created at the time when the security credentials are exchange and provisioned". Weird phrasing! "When the relationship is instantiated (e.g. when a subject is employed by an organisation) security credentials will typically be exchanged and credentials provisioned" makes a bit more sense. Sec 5.2 para 1 - s/intermediares/intermediaries Sec 5.2 para 1 - "are typically operate" - change wording. Sec 5.2 para 1 - "The relying party does not have a direct contractual relationship with the user" - I'd add a typically in there or something, as it's entirely possible the user might in certain cases. Sec 5.3 para 1 (line 5) - s/like/likely Sec 5.5 para 1 - Sentence starts with "While" but doesn't end appropriately... -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: [email protected] / [email protected] GPG: 0xDE2F024C On 9 Jul 2012, at 11:57, Jim Schaad wrote: > This version has had a substantial rewrite on section 2. The new version > makes it more clear what protocols are used where and gives some of the > reasoning behind the selection of the protocol. > > Comments and suggestions are gladly welcomed. > > Jim > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of [email protected] >> Sent: Monday, July 09, 2012 10:14 AM >> To: [email protected] >> Cc: [email protected] >> Subject: [abfab] I-D Action: draft-ietf-abfab-arch-03.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Application Bridging for Federated > Access >> Beyond web Working Group of the IETF. >> >> Title : Application Bridging for Federated Access Beyond > Web >> (ABFAB) Architecture >> Author(s) : Josh Howlett >> Sam Hartman >> Hannes Tschofenig >> Eliot Lear >> Jim Schaad >> Filename : draft-ietf-abfab-arch-03.txt >> Pages : 44 >> Date : 2012-07-09 >> >> Abstract: >> Over the last decade a substantial amount of work has occurred in the >> space of federated access management. Most of this effort has >> focused on two use-cases: network and web-based access. However, the >> solutions to these use-cases that have been proposed and deployed >> tend to have few common building blocks in common. >> >> This memo describes an architecture that makes use of extensions to >> the commonly used security mechanisms for both federated and non- >> federated access management, including the Remote Authentication Dial >> In User Service (RADIUS) and the Diameter protocol, the Generic >> Security Service (GSS), the GS2 family, the Extensible Authentication >> Protocol (EAP) and the Security Assertion Markup Language (SAML). >> The architecture addresses the problem of federated access management >> to primarily non-web-based services, in a manner that will scale to >> large numbers of identity providers, relying parties, and >> federations. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-abfab-arch >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-abfab-arch-03 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> abfab mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
