OASIS Provisioning Services Technical Committee (PSTC)
Meeting Minutes

Logistics

Meeting Date	11/19-20/2002
Meeting Time	9 - 5
Location	Redmond, Washington hosted by Microsoft
Duration	2 days
Chair	Darran Rolls
Recording Secretary	Gavenraj Sodhi
Agenda	As published as of December 8, 2002

Roll-call

Present

(JB)	Jeff Bohren, OpenNetwork Technologies
(GS)	Gavenraj Sodhi, Business Layers
(MP)	Mike Polan, IBM
(RE)	Rami Elron, BMC
(DC)	Doron Cohen, BMC
(DR)	Darran Rolls, Waveset
(ML)	Matthias Leibmann, Microsoft
(YK)	Yoav Kirsch, Business Layers

Minutes

Motion: Suggestion to rename PSU-ID so it may signify more than just a user.

Action: PSU-ID to be renamed as PO-ID (Provisioning Object ID) to be able to handle other objects than just user.

Discussion:

PSP – PST Discussion

Expanding Support (confirm with Jeff): Flexible for identities

Create identity from PSP

Pass back data from PSP to RA

Come up with Asynchronous model to support DSML

Unique identifier has been posed with “transactions”

Should we explain the difference between PSP and PST?

- PST almost assumes to operate like a PSP.

Review Goals:

Deliverables:

- Core Spec document (Darran)

o Request response protocol which DSML does not have

o Have to come up with an Asynchronous model

- Schema (Jeff/Yoav – Core Operations and Request Response)

o Two bodies of schema

o Request response ID model

o Additional operation at request responses level

- Use Cases (Gavenraj, Darran, Yoav)

- Glossary (Darran)

o Addendum: Create and add need further definition

- Business Paper (Gavenraj)

o Enterprise Focus

o Application Providers, Vendors…

(From Diagram)

CRUD – Create, read, update, and delete response

New method types as a discussion topic with R/R batch topic. à Towards extensibility but enforcing conformance.

Note: Without batching, for PSP, you cannot do transactions.

JeffB: Do we want a simpler model for Single Request Response?

Motion: Support a batch and non-batch model.

Ordering batch discussion (parallel/sequential)

- in DSML, for parallel, responses come in whatever order, they choose to. Can correlate response to request. Can only specify ID on request when done in parallel.

Parallel/sequential model in request/response

- Must have unique number for each request

Requirements to drive what we have:

- Request response model to support parallel/sequential

- Request response ID taken from the DSML model

- In sequential, you get back an ordered return (Follow DSML model)

- In parallel, requester provides ID. (Follow DSML model)

- Follow DSML R/R model in addition of query operation for: Request status (async)

o Therefore, we are planning to add ASYNCHRONOUS capability to DSML for SPML

IT Provisioning

Cascading ASP/MSP approach

Non-account oriented

DSML v2 review and discussion

- Need to extend error types

- Obtain last segment type from Darran Rolls (he made a note about this)

Would not use DSML DN within SPML protocol but may use as the ID. (Fixed string which cannot change)

Liberty Alliance: no notion of creating ID. SPML may be able to do this.

Discussion of parallel/sequential/unordered batchrequest.

- Can have sequential/mandatory/ordered

- Can have parallel/unordered/ordered

We have to provide an asynchronous model.

How is asynch different from numbered/ordered/sequential?

- won’t get immediate response

What would have to add to make asynch work?

- ability to query status of request

- conformance issue (ability for server to send response to client asynchronously)

Need timeout/cancel to add

- SLA (Service Level Agreement)

o Maybe extension of onError function

o Basic timeout (server would give out at a certain time)

o Taking a specific action or leading to a specific action to be done (like rules)

o An attribute of the provisioning request may mean something to the systems in the downstream.

o Rollback may only respond to the PSP…

o Maybe other organization to work off the transaction processing we are talking about (e.g., BTP)

o **Consider how we can extend onError capability… These are attributes of our batch request

§ How we address this in specification…** (Issue)

Issue: ** Provisioning w/ pure DSML

- **Leave AuthRequest in and make it an identifier.

o Detail of principle of making request**

o From RA and PSP perspective

Same value returned in search request – Scope attribute schema that the RA would see.

- return modification tag in modifyResponse

PSP should have the ability to send notifications…

Issue to consider: Need to consider (SPML to have an identifier for modifyRequest as optional). – Side effects of request (changed attributes)

SearchRequest – DSML

- Replace dn with our own identifier

Add

- Add identifier response

- Pass back any attributes because of add

Delete

- Replace dn with our own identifier

Modify

- not supported

Compare

- not supported

Darran comment: - Why can’t we pass the delete of attributes to delete

Delete – very similar to modify information, however end result is deleted. à Can have schedule, calendar associated.

- use case to delete account

- Propose to “send attributes to delete attributes” à delete mailbox, dates….

(possible use case)

Making abstract request as a batch request but performing actions that are just requests (batches of batches).

- consensus is batching is not as important within SPML versus DSML

Comment: Batch Request and Response should be request/response

- Common convention should be used and known as Batch Request and Response.

Going through current state of SPML

- Have to have a section on extensibility within the core document.

- Specify recommendations on extensibility

- Issue: New extensions will be popping up

Microsoft Example of provisioning application:

<Data>

<Attr>

<…>

</procedure>

Core Operations

- No deleteResponse

Cover exclusions when doing real spec is what we support but are DSML exclusions

Add GUID as identifier

Add URN to the list of simple identifiers

Need section to cover uniqueness and identifiers

- Motion: Canocilization of entire SPML identifier, including its type, has to be unique. - Done

Change DSML resultCode to SPML resultCode

We need to bring the objectclass from DSML to SPML.

Objectclass in addRequest (RA – PST object class discussion) is tabled for right now.

- Use this for: something might be an INetOrg account but also a Windows 2000 domain user. The union of those accounts defines the attributes of those accounts.

Glossary term clarification

Add- add a unique identified entity in the PSP

Modify- modify a previously created identified entity in the PSP

Delete- delete a previously created identified entity in the PSP

Add, modify, delete, search

Arbitrary Procedural request

One arbitrary request type (Option class is specifying the action)

Option 3 (Conrad):

<Data>

-----

<Action=stuff>

<Data>

Specific Example

<spml:ID>______</>

<Data>

<Value>

Motion: Proceed with motion #2 (Fixed operation/single extension)

- Motioned passed

Food for thought

Generic Self-Enrollment UI (As anonymous)

Wednesday

Use case for PST-ID

Day 2

Request/Response

Add Request

Modify Request

Delete Request

[query schema]

Extended Request

**Keep use cases in about users…

Motions and Actions

SPML-IDs (Unique)

Batch + non-batch support

Fixed operations/single extension model

PSU-ID renamed

Assigned edits:

- Spec – DR/++

- Schema – JB/YK

- Use Cases – GS

- Glossary – DR

- Biz Paper – GS/++

Why DSML

1) DSML is an approved OASIS standard

2) DSML is mature (v2)

3) DSML is in products today (MS DSML…, Sun DSML JNDI … )

4) Good fit for LDAP based provisioning systems and identity stores.

5) Model Simplicity (not tied to concrete decisions like provisioning)

- Provisioning a service is just not passing data

- Extending envelope data information

- Check status and cancel operations

Doron Comment: Third-party business applications to request services from provisioning systems. (RA-PSP)

How does the identifier extend the identifier type? (e.g., SS#)

Any entities can agree and extend to add further types…

Motion: Accept Model #2 as current direction

Add, modify, delete, search, extended request

- passed

Applying time based context on operations: Discussion

Issue of using modify as delete

- Do we feel delete operations of modify should be collapsed types

- Specification on each action as a transaction.

- Extended request

Comment: Should not be loaded on attributes

JB: Deleting may become very domain-specific; semantics of delete should be very clear and simple.

DR: Timing has been taken out.

Motion: All actions will have control attributes

1) Add operation attributes to all operations (no one opposed)

2) Add opec attribute operations in the batch (Tabled)

Consider increased complexity – For discussion

Recommend the object model has owner attributes

Do we understand: relationship between (RA-- PSx-IDà PSTD_ID)

Motion: Have PSx modeled in this fashion?

Issue: Implementation will be the final key and decider for final attributes including PSx.

Table to review.

Schema Discussion: JB

Add Darran’s notes

After 1.0 à need to look at standardized schemas

Break… (12:00 p.m.)

<spml: batch Request>

<spml: add Request>

We need to make this asynchronous batch request.

<spml: batch Request>

<spml: Request attributes>

From DSML:

<spml: batch Request requestID=”xlab” Processing=”sequential” ordering=” “ execution=”synch/asynch”>

<spml: Request attributes>

Comment: We have not stated what binding to use except mentioning SOAP.

Let’s talk about Request/Response over SOAP/HTTP.

- <spml:batchcancel requestID=”x1ab”>

- <spml:batchstatus requestID=”x1ab”>

What should a cancel request return?

- <spml:batchcancel requestID=”x1ab” returntype=”response”>

o Request ID may or may not be required (requested by Rami)

(RA—PSP)

Comment: Should have Notification Usecase

Comment: Should have Asynchronous Notification Usecase

Doron Comment: Value to trace origin of change (side effect). (Cause and Effect)

Yoav Comment: Side effect should pass information, which is not account related.

Doron Comment: Don’t put entire request in the response…

** JB Middleground comment: Have operation attributes on all operational responses.

Request ID = mandatory (??) à Take as open issue

Action Items & Motions

	Owner	Action Item
1		Suggestion to rename PSU-ID so it may signify more than just a user.
2	Misc.	Assigned edits: - Spec – DR/++ - Schema – JB/YK - Use Cases – GS - Glossary – DR - Biz Paper – GS/++
		Add additional Notes from members (Darran, Jeff, …)

	Motions
	PSU-ID to be renamed as PO-ID (Provisioning Object ID) to be able to handle other objects than just user.	Email discussion
	Support a batch and non-batch model.
	Canocilization of entire SPML identifier, including its type, has to be unique.	Accepted
	Proceed with motion #2 (Fixed operation/single extension)	Accepted
	Accept Model #2 as current direction (Add, modify, delete, search, extended request)	Accepted
	All actions will have control attributes 3) Add operation attributes to all operations (no one opposed) 4) Add opec attribute operations in the batch (Tabled)
	Have PSx modeled in this fashion?
DR	Motion to adjourn	Accepted

OASIS Provisioning Services Technical Committee (PSTC) Meeting Minutes

Logistics

Jeff Bohren, OpenNetwork Technologies

Gavenraj Sodhi, Business Layers

Mike Polan, IBM

Rami Elron, BMC

Doron Cohen, BMC

Darran Rolls, Waveset

Matthias Leibmann, Microsoft

Yoav Kirsch, Business Layers

Minutes

Glossary term clarification

Specific Example

Wednesday

Day 2

Motions and Actions

Why DSML

Action Items & Motions

OASIS Provisioning Services Technical Committee (PSTC)
Meeting Minutes