Subject: Re: [scim] Design Team Status

From: Bjorn Aannestad <[email-masked]>
Date: Mon, 29 Oct 2012 18:00:16 -0500

Here's my attempt to turn these into new, specific items for the issues 
tracker.   Take this as a proposal for issue titles.  Then, the 
discussions on the merits and details of each can proceed.

Object relationships:
- Should the spec define how to create and traverse parent-child 
relationships and/or arbitrary relationships, or stay as-is?

Keep existing info model or adopt other.
- Should the spec adopt the vCard  model?
- Should the spec define a "human person" resource, and then define and 
allow "user" and other derived types?
- Should the spec define an "application" resource, for use e.g. with 
OAuth client provisioning?

Entitlements:
- Should the spec define a basic model for entitlements?  If so, define 
it (existing Issue #11).

Meta-data:
- Should the spec define metadata on each attribute?  If so what is 
standard and what is extended?

Query improvements
- Define support for a negation operator in queries
- Define a method for retrieving a resource when its type is not known, 
only its id
- Allow queries to return only values that match the query (Search for 
groups with member foo, but only return member foo and not all members)

Passwords  (overlaps existing issue #14)
- Should there be an extension for Password Management and Policies?  If so,
     - Method for retrieving machine-readable password rules defined by 
the provider?
     - Define attributes of "User" for password & log in metadata
     - Method(s) for password expiration flows (both pre- and 
post-expiration)?
     - Method for requiring and sending current password with a password 
reset
     - Method for verifying that a new or changed password matches rules 
defined by the provider
     - Method for checking that a client-supplied password matches the 
one stored by the provider

Other
- After group approval, remove requirement to support XML
- Propose text to address case preservation
- Propose text to clarify the spec position on multi-tenancy
- Propose text to improve/clean up PATCH operation (existing issue #18)
- Propose text to resolve search query parameters via GET URL or POST

REST pattern (URL modeling, filter semantics, object naming rules)
- I'm not sure what the specific issues are in this one.

-Bjorn

On 10/29/2012 10:43, Trey Drake wrote:
> The design team has identified and is actively working the following 
> issues:
>
> Schema:
> - Object relationship (children objects?)
> - Keep existing info model or adopt other.  vCard is in the running. 
>  Key consideration is extensibility.
> - Remove XML data model. Spec JSON only?
> - Metadata on each attribute (possibly on each value). Provides the 
> ability to set meta-data describing an attribute's: creation date , 
> expiry date, source,  if verified, etc.
> - Attribute value case preservation (e.g. ExternalID). Must the 
> service provider respect the consumer case sensitivity?  Problematic 
> w.r.t. indexing, et al.
> - Entitlements – remove from spec and make it extension or define 
> basic model
>
> API:
> - Re-visit the API.  Should we further elaborate the API/response so 
> that it is more Graph like a la oData? For example, embed Group/user 
> relationship/references?
> - Multi-Tenancy clarifications
> - REST pattern (URL modeling, filter semantics, object naming rules)
> - Patch improvements/cleanup
> - Query/filter semantics improvements: return only values that match 
> the query (not all values – ex. Search for groups with member foo, but 
> only return member foo and not all members), negation
> - Search query parameters via GET URL vs. post?  If POST there is a 
> case to be made to introduce a search operation; e.g., X-SEARCH vs GET 
> overloading
> - Password management and policy – should this be spec'd now, later or 
> simply handle as an extension?
>
> Thanks,
> Trey
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

-- 
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:[email-masked]  | 512-769-6461

---

From: Melinda Shore <[email-masked]>
Date: Mon, 29 Oct 2012 15:49:56 -0800

> discussions on the merits and details of each can proceed.

As a matter of process, anybody with an account can create tickets or
edit existing ones (not sure about closing them).  Allow me to suggest
that it's more productive to go ahead and create tickets than it is
to debate them first.  On the other hand, it's not a good thing to
get lost in a sea of tickets.

More generally, I'm not sure that having high-level design questions
in the ticket tracker is that productive - they should probably be
specific and on point.  "Remove requirement to support XML" is a good
ticket subject.  "Should the spec define how to create and traverse
parent-child relationships and/or arbitrary relationships, or stay
as-is?" is probably not great, but once a decision is made and if
it requires a change to the spec, "write text defining the creation and
traversal of parent-child relationships" is something that can be
done and be closed.

Melinda

---

From: Leif Johansson <[email-masked]>
Date: Tue, 30 Oct 2012 11:10:09 +0100

> traversal of parent-child relationships" is something that can be

Those are very good points. Lets make the tickets actionable!

---

From: Bjorn Aannestad <[email-masked]>
Date: Tue, 30 Oct 2012 10:06:00 -0500

Thanks for the guidance, Melinda -- that works for me.   Is there a 
consensus on which items are ticket-worthy?  I'm happy to create some or 
all of them, as needed.

-Bjorn

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Oct 2012 16:08:58 +0100

I think Melinda said that anyone can create tickets, so how about
shooting first and asking questions later?

;-)

Eliot
On 10/30/12 4:06 PM, Bjorn Aannestad wrote:
> consensus on which items are ticket-worthy?  I'm happy to create some
> or all of them, as needed.
>
> -Bjorn
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 30 Oct 2012 09:16:03 -0700

I believe Morteza had some updates from iiw. Not sure if he has already applied them or still pending. 

Phil

On 2012-10-30, at 8:08, Eliot Lear <[email-masked]> wrote:

> I think Melinda said that anyone can create tickets, so how about shooting first and asking questions later?
> 
> ;-)
> 
> Eliot
>> Thanks for the guidance, Melinda -- that works for me.   Is there a consensus on which items are ticket-worthy?  I'm happy to create some or all of them, as needed. 
>> 
>> -Bjorn 
>>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Oct 2012 09:06:14 -0800

> shooting first and asking questions later?

I think this is reasonable, but should not be taken as a license
to create tickets for things which have not been mentioned on the
list.  If things get out of hand or there's clear misbehavior we can
put access controls on the issue tracker, but for the time being
there seems to be more benefit than not to having it open.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Oct 2012 10:10:12 -0800

Speaking of the issue tracker, this might be a good time to start
going through the tickets and closing the easy ones.  I think most
of them require some effort but a few do not, particularly.  For
example, #7 ("The Canonical types for groups attribute begins with
capital letter, but all other are lowercase") appears to be just
editorial.

Melinda

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 30 Oct 2012 19:04:47 +0000

The nice thing about capital types for the members attribute on the Group resource is that the type value corresponds to the resource name.  In other words, given a group you could traverse the object relationship to the member.  Something like this:

    resource = GET /Schemas?name eq {member.type}
    GET {resource.endpoint}/{member.value}

Of course, with a lowercase name you could just upper case the first letter.  To me it is a little more apparent with the upper-case letter.

On the other hand, this might become a moot point depending on how we address this: "Should the spec define how to create and traverse parent-child relationships and/or arbitrary relationships, or stay as-is?".

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, October 30, 2012 1:10 PM
To: [email-masked]
Subject: Re: [scim] Design Team Status

Speaking of the issue tracker, this might be a good time to start going through the tickets and closing the easy ones.  I think most of them require some effort but a few do not, particularly.  For example, #7 ("The Canonical types for groups attribute begins with capital letter, but all other are lowercase") appears to be just editorial.

Melinda

---

From: Leif Johansson <[email-masked]>
Date: Tue, 30 Oct 2012 22:54:20 +0100

> shooting first and asking questions later?

As chair I'd rather have actionable issues than no issues. But I'd
_love_ to have both :-)