Re: [abfab] charter take 3

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2010 01:00 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> 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."

Actually it was Daves paragraph but I suggest you comment on the version
Josh just suggested for the first paragraph. It might parse more easily.

On this note I urge everyone not to bike-shed on an explanation of what
constitutes federated identity. We have plenty of time for that _if_ we
can get to a point where we can talk about working group documents ;-)

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

There are plenty of protocols not done in the IETF but I take your point
and will try to polish that up a bit.

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

god point.

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

yes.

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

That aside think your version reads better.

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

Imho that would be silly. Everyone knows the web runs on HTTP.

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

Elliot has suggested dropping those paragraphs actually...

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

possibly.

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

Why? There has been lots of discussion on the list about the need to
allow for future introduction of new application interface technologies
but that the WG would start with GSS-API. Initially is meant to convey
precisely this and I've not heard any opposition to it so it stays
unless I hear lots more support for dropping it.

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

I presume you are talking about the last paragraph and not all three?
In that case Elliot has suggested dropping that text already (he was
the originator of the usability concerns).

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

See above wrt Elliots suggestions.

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

Does that have to go in the charter?

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

I think we have to before Sean would be happy :-)

	Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxlLJoACgkQ8Jx8FtbMZndJegCfUjaSrdapHA1NnRq3IAf8ynxF
LLsAnjesTRQqTnTsTRMMTt2ekB6b/M7R
=h+D3
-----END PGP SIGNATURE-----