[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [provision] Summary of 12/17/2001 working group call
The following very broadly outlines the items discussed on today's working group call, highlights the conclusions and the action items agreed upon. If I've missed anything important or have failed to capture comment or sentiment accurately please feel free to say so. The discussion was framed around the following 4 questions: ============================================================ 1) Is AuthN and AuthZ of requesting authority (RA) in scope? 2) Is the specification open to provision any service or resource on the basis that: a) RA is authorized to do so b) RA has obtained (or otherwise knows) the identity of the service/resource c) RA has obtained (or otherwise knows) the required schema of the target service 3) How much of the target resource schema do we need to stipulate? 4) Is a federated or chained model in scope (A send request to B who sends request to C, C completes provisioning) and if so: a) Can B change A's request b) Does C see A and know of amendments made by B ==== Re 1 ==== - Operation of AuthN would be considered out of scope. The context of AuthZ would not be negotiated by the framework but would be expressible in some element of the request vocabulary (NOTE: I'm a little unsure what this buys us and if it meets the needs of the case Tony spoke of. Tony please expand if this does not sound right or capture the reasoning behind the comment). - Specific security consideration should be discussed in the finished specification document (like SAML). ACTION: DR to send a cross posting to the SAML list (and someone mentioned Phillip HB specifically) to comment on the possible use of SAML within provisioning. ACTION: Add not on security consideration to specification outline. ================= Re 2 & 3 Combined ================= - Possible base schema for all resources defined around a service. Jamcracker supplied a comprehensive service definition from an ASP view point. Agreed we should review this and other use cases. - Some concern over the progression of use cases before a redefinition of the charter. General agreement that these efforts support each other and could therefore proceed in parallel. - General agreement on importance of terms. Everyone should read the individual submission draft-rolls-glossary-01 and start to merge use-case term and other descriptions submitted to the list. Agreement we should form a responsible individual/group for the glossary moving forward. ACTION: Review an updated charter prior to January 7th con-call with a view to taking a vote ACTION: Everyone to concentrate on terms for the glossary and on submitted use cases. ==== Re 4 ==== - Strong need to support the chaining of requests for ASP and web service models. Yoav expressed concerns over the complexity this could introduce. - Concerns over security and transactional context. ACTION: Tony to dig out and update the XRPM notions of a Peer-to-peer provisioning model and submit as an outline use case. ACTION: Yoav - perhaps you could outline the basis for your concerns regarding chaining of requests - if there is a valid concern we need to consider it. ACTION: Winston to publish documents on the site. ACTION: Everyone to make future substantive committee submissions in conformance with proposed documentation standards. -------------------------------------------------------- Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com (512) 657 8360 PGP 0x8AC67C6F --------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC