OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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

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

- 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