Notes of GGF 17 OGSA Authz meeting, 10 May 2006 AGENDA Admin (scribe, note well etc.) Update of progress since last meeting Report of 2 recent telephone conferences Views about proposed revised charter Continue discussions on 2 draft protocol IDs Date of next telephone conference AOB Significant progress has been made since the last GGF meeting. The Charter has been revised and there's been some inconclusive discussion about it on this list. Two ID's have been published, PDP and CVS protocol specs. In addition there has been two long telephone conferences (minutes have been sent to the list). The first phone conference suggested that the charter should be slimmed down dramatically and should only fit the work we can do ie. produce documents that we have editors for. The phone conf suggested 3 docs: 1. Java interface for plugging different authorization functions (PDP, PIP, etc.) into an Apache Axis-based Grid Services runtime. The GT team have volunteered to edit this. 2. Two protocol IDs for the next generation Authz protocol(s) to replace the current SAML one. Editors David Chadwick et al; First is a protocol to interact with an XACML PDP, the second is WS-Trust interaction with a credential validation service. SAML assertions are not deprecated; instead, they are imbedded within XACML, and returned by WS-Trust. 3. Third is an authz scenarios and requirements document which needs an editor. None was forthcoming during the meeting itself. New Charter will be republished shortly and will be ready for discussion at the telephone conference in two weeks. Are the protocol Drafts true specifications, or are they either descriptions of current implementation or what future implementations should look like? Ans. They are primarily Profiles of current standards. The telecom and meeting agreed that we should generalize the authz protocols to allow the functional components to talk to each other in different configurations. That would be of much more interest to Internet2 and MSFT. Should we build on XACMLv2 or V3, since v3 isn't stable yet. XACMLv3 offers true delegation of policies and partial rights, but we're not sure whether that's much of a requirement at the present time because you can delegate attributes that are built into the XACML expression. A canvas of requirements in deployments would be important here to assess full delegation requirements at present. David Chadwick's team have reported a problem to the XACML committee that the interface is for synchronous requests only. Anne Anderson has said that the XACML group will to look at this issue and the various solutions to it. Can an XACML PDP's act as credential verification services? If the PDP could be asked in an XACML format whether a given credential were valid or not, then there could be a flattening of the space. We don't know whether XACML has the full range of functionality required of a credential validation service, since that wasn't a primary goal in its design. Architecturally, there's no need to separate this functionality; this is an implementation-time choice. The list of requirements for a CVS isn't part of the deliverables yet. It was agreed that understanding of what will be required from a CVS will dictate what the other deliverables will be. David agreed to circulate a copy of this list of draft functional requirements to the group for comment and further contributions. Olle mentioned the importance of having a framework approach and a profiling of the framework. Instead, we're looking at specific versions of specific technologies. Maybe they should be separated. David agreed to separate out the functional components diagram into a separate document to be a separate deliverable of the group, and to show the different ways in which the components can be architected together.vThe variety of potential groupings should be discussed and understood especially in light of the effect they will have on the protocols. Olle believes we really need a requirement doc; if the barrier to doing so is the amount of effort that would be poured into producing a GGF document, then instead we can have a more lightweight mechanism. Olle suggested that if a wiki was provided then many people might contribute their requirements into it. Alternatively, each protocol doc could imbed the requirements in the documents itself. It may be desirable for the many legacy authz monoliths that we have in place to be able to define a simple new service and be "future-proof". In some ways, the monolith call out is simpler for the application as well. Next telecon is Tuesday 23 May, 4pm European time, 3pm UK time, 10am Eastern, 7am Pacific and 11pm Japan. Frank Siebenlist will set it up The meeting ended at noon.