Re: [abfab] charter take 3

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Lef, 

Thanks for getting this going. A few minor comments. 


> 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.


I am trying to parse this sentence and I does not make sense to me. 

First, I think you are trying to say "Federated Identity Management
Systems share"
(let's assume that such a term exists somewhere)

Second, "share ... User identity information and related attributes" 

(you see that the terminology document that I distributed recently would
reallly be useful)

What does it mean to say "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.


Which non-IETF protocols? 
I would you would say non-HTTP based protocols. 


  The design will combine existing IETF protocols,
> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). 

SAML is not an IETF protocol. 
Maybe you want to say 

"
The design will combine existing protocols, namely the Extensible
Authentication Protocol (EAP - RFC 3748), Authentication, Authorization
and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and
the Security Assertion Markup Language (SAML). 
"

(I put SAML as the last item because it is the least important one in
the approach discussed on the list. Everything would just work without
using SAML as well.)


>  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,

Authenticate and authorize users for non-HTTP based applications. 

> this working group will look at approaches that do not rely 
> on the web,


... On the HTTP-based 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.

What do you mean by passing structured data to an appropriate
authentication interface? 


> 
> The working group will develop a solution for federated identity for
> IETF and non-IETF application protocols

I would prefer to write "for non-HTTP based protocols". 

> by combining SAML, EAP (RFC
> 3748) and AAA (RADIUS, Diameter).


Btw, you said that already previously. Maybe you want to merge the text
with the previous paragraph to make it less repetitive. 



 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.
> 
> 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

... Other alternative technology for these three communication
relationships.


> 
> Constraints:
> - ------------
> 
> Initially the working group will focus on using GSS-API (RFC2743) as

Remove the initially 


> 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.
> 
> The working group will ensure that any solution developed has built-
> in technical controls for privacy protection.
> 
> 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
> 
> 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.


Hmmm. I am not happy with this text. Where else would you like to do
such work in the IETF other than in the group where the experts of the
technology are. Why not to work on a document that illustrates the
issues and if there are suggestions to make then just make them. 


> 
> 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.

This sounds a bit fuzzy. What do you mean by "additional components"? 
Are we talking about user interface issues or protocol extensions that
simplify operations and management (i.e. the user in the sense of the
administor of the system). 

> 
> 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.

So, what do you expect OASIS to do in this work? 
Review? 
Be aware of the IETF group? 

Because of the different organizational structure and membership model I
am always concerned when work is spread over different SDOs. I am
chairing the KEYPROV working group and we had some interactions with
OASIS and I am not sure OASIS has been helpful in any way. Why do you
think it is different here? 

> 
> 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

Sounds good to me. Are you going to propose milestones as well? 



Ciao
Hannes