Re: [abfab] charter take 3

[Dave CROCKER <[e-mail]>]

Leif,

The charter looks much better.  I've still got a few questions, but now they are 
relatively narrow and specific:


On 8/13/2010 12:32 AM, Leif Johansson wrote:
> Abfab Proposed Charter
>
> Abfab - Application Bridging for Federated Access Beyond web
>
> Federated identity shares user authorization information among
> organizations, without specific registration of the individual user at
> the organization controlling a a remote resource.  A number of such
> mechanisms are in use for the Web.  This working group will specify a
> federated identity mechanism for use by other Internet services, such as
> IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web
> protocols.  The design will combine existing IETF protocols,
> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter).  With the
> deployment of the solution, a user from one organization will be able to
> access resources at another organization, given only prior agreement
> between the organizations, or prior agreement between each organization
> and a trusted intermediary.
>
> While work continues elsewhere on basic mechanisms that rely on using an
> HTTP/HTML interface to authenticate and authorize non-web applications,

As noted (or at least implied) by another posting this morning, perhaps this 
should simply say:

      ...that rely on using an HTTP/HTML interface for authentication and 
authorization...


> this working group will look at approaches that do not rely on the web,
> taking into account user interface concerns and the need to pass
> structured data to an appropriate authentication interface, as well as
> the need to handle large scale discovery.

On reflection, I'm not clear what the purpose of citing the outside work is.

The more I re-read this second paragraph, the more I believe it adds no value. 
I suggest simply deleting it.


> The working group will develop a solution for federated identity for
> IETF and non-IETF application protocols by combining SAML, EAP (RFC
> 3748) and AAA (RADIUS, Diameter). Specifically EAP will be used to
> authenticate the subject to a trusted party, AAA (RADIUS and Diameter)
> will be used to authenticate and convey information from that party to a
> relying party and SAML is used for authorization and personalization.

IF there is a practical import to citing "non-IETF" applications, I don't know 
what it is.  The charter should either make that real in technical or process 
terms, or it should delete the reference to the 'homes' of application 
specifications.

So, I suggest:

     The working group will specify a federated identity service for use by 
applications, by combining...


> The working group may consider other alternative technology for these
> three roles in the architecture but any change in direction in this
> respect requires rechartering of the working group.

I typically dislike references to hypothetical futures and especially to things 
that might be considered but which will require rechartering.

In this case, however, I think it defines a high barrier for replacing the 
technical components and it hits the reader in the face with how much effort it 
will take to climb the barrier.  So, I like it.


> Constraints:
> - ------------
>
> Initially the working group will focus on using GSS-API (RFC2743) as
> a mechanism for integrating the developed solution for federated
> identity into application protocols but other technologies for
> application interface are in scope of the working group and may be
> adopted as deliverables subject to the normal IETF consensus and
> (re)charter process.

    developed solution for federated identity
    ->
    federated identity service

(yes, this is the second placed I'm suggesting moving from 'solution' to 
'service' and using somewhat more direct language.  i think it makes a 
difference to the reading.)


> The working group will ensure that any solution developed has built-
> in technical controls for privacy protection.

I still have no idea what this means either conceptually or in terms of working 
group work.


> The working group may not change EAP (beyond the development of EAP
> mechanisms), RADIUS or Diameter without establishing consensus with
> the appropriate community within the IETF.
>
> The working group will use the following documents as a starting
> point for its work:
>
> - - draft-howlett-eap-gss-00,
> - - draft-howlett-radius-saml-attr-00
> - - draft-hartman-gss-eap-naming-00

I'm pretty sure these are more than "starting points". That's a pretty vague 
term and I think you folks intend something more specific and that it means 
significant constraints on the changes to these specification that are 
considered permissible.

These are the base specifications.  What are the criteria for making changes to 
them?

That's what the charter should say, unless you folks have a different intent.


> Concerns have been raised that additional work is required in keying
> AAA associations in a federated environment. The working group is
> chartered to explore these concerns and if needed, specify protocols
> that use existing AAA key management mechanisms to address these concerns.
>
> In addition, the working group will explore the usability and user
> interface issues associated with federated authentication. The work is
> not chartered to standardize protocols or recommend best current
> practice in the area of usability. The working group should explore
> the area and produce informational documents describing the issues and
> recommending appropriate work for the IETF in this area.
>
> As future work in dealing with user interface in this area progresses,
> the architecture of the system may need to expand to include additional
> components or make significant changes to adapt to improvements in
> understanding of user interface. In describing architecture work, the
> working group will emphasize this possibility of change.
>
> Coordination with other SDOs
> - ----------------------------
>
> This work will require close coordination with work going on in the
> OASIS Security Services Technical Committee (SSTC). There should be
> sufficient overlapping participation between the SSTC and this working
> group for informal coordination. The chairs of this working group may
> work with the SSTC chairs and the IAB in case formal coordination is
> required.
>
> In particular coordination is required with respect to the SAML-RADIUS
> binding.
>
> Deliverables
> - ------------
>
> The deliverables of the working group are:
>
> * A document describing applicable use cases.
>
> * An architecture document describing how the components of the solution
> fit together to address the use cases and open issues that will require
> future changes to the architecture
>
> * A standards-track protocol for carrying SAML messages in RADIUS and
> Diameter
>
> * An update to the EAP applicability statement in RFC 3748 describing
> the applicability of EAP to application authentication and placing
> appropriate requirements on this new EAP use case
>
> * A standards track solution for using EAP methods to provide
> authentication within the application
>
> * An update to the EMSK root key applicability statement in RFC 5295
>
> * A standards-track description of GSS names and name attributes
> required by the solution
>
> * Informational descriptions of usability and user-interface concerns
> related to this work
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxk9RAACgkQ8Jx8FtbMZnc5sACgjZA9qFQLI9PWajoNF5DXWj/O
> 4NQAnidUYYfyrcoOqvgfFeGRURQ1wh48
> =gRBO
> -----END PGP SIGNATURE-----
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net