Prateek Mishra (Oracle)
Dale Olds (Novell)
Agenda:
1) Roll Call and Agenda Review
2) Minute Taker Nomination
3) Approval of Aug 16th Meeting Minutes
4) Discuss the goals going forward for the PSTC
5) Discuss the PSTC charter and whether or not it
should be updated
6) Discuss updating the PSTC web site
7) AOB
1) Roll Call and Agenda Review:
- Gary took roll.
- Quorum was achieved:
-- Quorum requires more than 50% of voting
members.
-- Richard called Dan Perry, who joined, so that 6
of 10 voting members were present.
- Voting status changes: none.
2) Minute-taker Nomination:
- No one nominated a taker of minutes.
- Gary accepted responsibility to take notes for this
August 30 meeting.
3) Approval of Aug 16th Meeting Minutes:
- Attendees approved minutes from Aug 16 without
objection or modification.
4) Discuss goals for PSTC:
- Gary suggested that the committee identify and
examine use-cases before deciding whether a new version of
SPML is required.
-- If SPMLv2 adequately addresses those use-cases,
then we may need only examples or perhaps a new profile.
-- Any fundamental inadequacy of SPMLv2 in
addressing those use-cases could justify a new major/minor
version.
-- Richard agreed, saying that he had separately
reached a similar conclusion.
- Participants agreed to post to the list use-cases
that SPML should address.
- Participants verbally outlined several types of
use-cases that SPML should address.
o "The Connector Problem" was summarized as follows:
-- Current provisioning systems require proprietary
connectors.
-- The vendor of an application (or the deployer of
an application) may need to develop such a connector
or may need to expose management interfaces to
support multiple proprietary connectors.
-- Customers of an application may be unable to
provision to the application
unless they buy and deploy (proprietary
connectors as part of) a provisioning system.
o ID Cloud requires "Bidirectional Synchronization
Between Enterprises":
-- The goal is to use SPML as a "means to an end":
--- the goal is exchange of attributes across
organizational boundaries
--- perhaps use SAML2 meta-data (or something
analogous) to describe available operations
-- For example, FEMA needs to exchange the attributes
of federal responders
--- each department (e.g., DoD, DHS) assigns
people and maintains attributes of those responders
-- Not a problem with the schema or the payload.
Instead, the Issue is "scale":
--- Search Capability and Updates Capability
impose a significant data-management burden on each PSP
--- Need ability to limit (i.e., specify in
schema) which attributes can be used in search queries.
o Requirements for "Provisioning to Cloud-Based
applications" (ask Nishant Kaushik or Mark Diodati):
-- Multi-tenancy
-- Standard protocol for provisioning to cloud (and
to applications in the cloud)
o Richard Sand proposes adding specific, "Higher-Level
Management Operations" that reflect the lifecycle of
identities:
-- e.g., onboarding, off-boarding, delegating
responsibilities, adding/removing membership in roles.
-- Don't want to rely on shared / common schema.
-- Define these as Operations (perhaps within new
Capabilities that could be standardized).
o "Lower The Bar for a PSP" (seems to boil down to
eliminating required operations):
-- For example, SPMLv2 would consider the following
providers non-conformant:
--- A PSP that exposed only Password-Change
operations.
--- A PSP that exposed only 1) the ability to
list unique IDs of users with attribute X (e.g.,
responders);
and 2) the ability to request a batch dump
of all the attributes for those users.
-- Eliminate the requirement to support
listTargets, and core operations.
-- Define a mechanism (other than listTargets) to
advertise which operations a provider supports.
o "Standard Schema" (as relayed by Anil John on behalf
of SPML SIG at Burton Catalyst):
-- Optional standard schema (a la inetorgperson) to
which providers and requestors can agree.
-- Gary pointed out that the schema URN mechanism
already allows requestors and providers to do this.
What seems to be missing is the "blessing" of the
PSTC or a profile that specifies a schema.
o "Conformance" and Interops:
-- Automated tests for conformance blessed by the
PSTC would be nice.
-- OASIS might have an issue, mainly because OASIS
has no software license:
--- Test Suites are okay. Samples are okay.
--- Reference implementations generally are NOT
okay (might have IP problems, subject to OASIS IPR).
-- Gary suggested that if OASIS cannot do something,
members could use another organization
(e.g., OpenSPML.org) to contribute certain
artifacts.
5) Discuss the PSTC Charter and whether or not it
should be updated:
- The current charter appears to be out-of-date and
does not adequately describe the purpose of the PSTC.
- Gary suggested that we discuss on the list a new
charter or changes to the existing charter.
- Richard pointed out that he had made some suggestions
in a previous email to the list.
** Please send to the list (and discuss on the list)
suggestions regarding the charter. **
6) Discuss updating the PSTC web site
- Discussed this only briefly (due to time
constraints).
7) AOB
- No additional items.
** Next meeting: Monday, September 13, 2PM Eastern Time
(UTC-05:00) Eastern Time (US & Canada). **