Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases
draft-ietf-abfab-usecases-05

Nit:
-- Section 3.1 --

Lots of editorial stuff, but it'll all be sorted by the RFC Editor.  One nit that might not be is this one:

   o  Common application software such as email, shared storage,
      business applications such as Customer Relationship Management
      (CRM) or scientific applications ("Software as a Service", or
      Saas).

The last letter of "SaaS" needs to be capitalized.

I support the publication of this draft. 


   Adding federated authentication to IPP [RFC3229] (and other relevant
   protocols) would enable this kind of remote printing service without
   the administrative overhead of credentialing these visitors (who, of
   course, may well one time visitors to the organisation). 

Are you sure it's the right RFC?


Regarding the next two comments, take them or leave them, up to the WG authors/chairs/AD


1. There are multiple sentences that speak about the ABFAB architecture and specifications.

-  The goal of this document is to document a selection
   of the wide variety of these contexts whose user experience could be
   improved through the use of technologies based on the ABFAB
   architecture and specifications.

-   This document enumerates some of these use cases,
   describing how technologies based on the the ABFAB architecture
   [I-D.lear-abfab-arch] and specifications could be used.

-  This document enumerates some of these use cases,
   describing how technologies based on the the ABFAB architecture
   [I-D.lear-abfab-arch] and specifications could be used.

-  ABFAB could help in this context as its specifications would enable
   federated authentication for a variety of non-web protocols, ...

-  The use of ABFAB technologies in this case would enable both the
   front or back end attribute exchange required to provide subject
   attributes.  

-  etc...

You chose to have a use cases RFC before the architecture RFC. That's your choice, and that's fine!
However, it would be nice to explain in one paragraph (potentially with a figure) how you envision the architecture:
    organization A,
    organization B,
    a user who authenticates in the org A and needs to access the information in org B
    a RADIUS connection from org. A to org B. with SAML content within the RADIUS data.
I had to dig outside of the draft to find this information, but it helped me tremendously to start to understand the technology challenges behind the use cases.
In 5 years from now, which RFC should a new newcomer read first to start understanding what the WG does? Is it this one or the architecture? 

2.  A sentence or two regarding the relationship with the ABFAB and SCIM use cases (in this document or in a different subsequent document, not sure)
As far as I can tell:
    SCIM: pre-provisioning identity management across domains
    ABFAB: Single Sign On across domains