Re: [provision] Standard Schema draft 4.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff, thanks for the excellent feedback. Initial responses inline below.

Bohren, Jeff wrote:

> Gary’s latest draft looks like good progress. Here are my suggestions:
>
>     * Contributors should be TBD for now.
>
That's easy.

>     * Remove the “Benefits of a Standard Schema” section.
>
That is also easy, but don't we want to explain somewhere our motivation?

>     * The Account Template object seems to Provisioning System
>       specific. That may well be how a specific system is modeled, but
>       seems inappropriate for a general purpose interface to a service.
>
I agree that the Account Template seems specific to Provisioning 
Systems, but is SPML truly a general-purpose interface, or is SPML a 
*provisioning interface* to a service? After all, the name is "Service 
Provisioning Markup Language".

The Domain Model for Identity Management intentionally includes the 
concepts common to provisioning systems. The AccountTemplate object 
class is optional; a provider that is not a provisioning system need not 
support it. We can remove this from the Standard Schema if we wish, but 
most RBAC schemes end up needing something like this.

>     * The Account should not have links to generic Account Attributes.
>
You are right, Account should not have links to generic Account 
Attributes. In actuality, it does not (and a note on Page 12 states 
this), but the dotted-line (which means implicit) relationship 
"HasValueFor" in the Domain Model *does* give this misleading impression.

I suggest removing "HasValueFor" from the Domain Model. Should I also 
remove "ImpliesValueFor" (which is also a dotted-line relationship)?

>     * GUID should not be a required attribute.
>
Let's talk about this. You know I like GUIDs (and PSO-ID is *almost* but 
not quite a GUID). I think it's a best practice. Why not require GUID?

>     * There are several “Roll-up” Attributes defined (orgs-indirect
>       and orgs-dynamic). These imply extra processing that may not be
>       desirable or feasible. For instance calculating the value for an
>       orgs-dynamic attribute when searching a 25M user service may not
>       be advisable.
>
Absolutely right; the descriptions for these attributes even note that 
they scale poorly. Of course, these attributes are *optional*. A 
provider that does not support them simply omits them. Conformance says 
that's alright as long as you're not exposing an equivalent attribute. 
Why not define them? If providers do expose them, they'll be interoperable.

>     * There are several attributes that duplicate SPML 2.0
>       capabilities. I dislike this approach.
>
Let's talk about this, too. Why do you dislike this? As the "Power" 
paragraph within "Benefits of a Standard Schema" explains, operational 
attributes allow a single request to perform what would otherwise 
require multiple requests (e.g., create an Account in a disabled state).

>     * There should not be a Roles-excluded attribute on the Role
>       object itself. This is too simplistic for real SOD.
>
You may be right; this may be too simplistic. However, it *is* quite 
common, and it is simple. Which is what I thought we were going for.

>     * The Question and Answer objects don’t seem appropriate for this
>       schema. I understand most IdM platforms support this, but again
>       we are not creating an IdM platform schema.
>
Questions and Answers are not specific to IdM platforms. Every web site 
I register with sets questions and answers. Pick from a standard list of 
questions, or add your own custom question.

>    *
>
>
> Jeff B.
>
> ------------------------------------------------------------------------
>
> *From:* Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM]
> *Sent:* Tuesday, March 27, 2007 1:23 PM
> *To:* PSTC
> *Subject:* [provision] Standard Schema draft 4.
>
> Took a while, but I've attached a PDF.
>
>     * This Introduction discusses SIMPLEST only as a schema (and not
>       as a profile of SPML). The Protocol section has been removed
>       accordingly.
>     * The domain model is the same (although I've tweaked the names of
>       the two entities in the lower-right-hand corner of the diagram:
>       AccountTemplate and AccountAttribute).
>     * The Schema section now reflects the object-classes and
>       attributes from the spreadsheet that I sent to (the list at the
>       time of) the last Face-to-Face.
>     * The Conformance section has been expanded. It now discusses
>       extensions to the standard schema as well as arbitrary (i.e.,
>       undeclared extensions) object-classes and attributes.
>
> Obviously, this is just a draft, but it fairly represents the current 
> proposal. This draft should serve as a basis for further discussion.
>
>     * I have not incorporated anything from SAP's submission to the
>       Standard Schema. I intended to do that, but it took longer than
>       I expected merely to bring the draft up to date.
>     * It feels a little weird to propose a standard schema without
>       specifying a schema language. Perhaps we can show how
>       (operations using) the standard schema would look in the DSML
>       Profile or SAML Profile or XSD Profile.
>     * The language in the Conformance section is still a bit tortuous.
>       I can make the language clearer, given time, so what I need
>       first and most is comment on the *ideas* in this section.
>