Subject: [scim] data format

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 09:18:40 -0600

While we're discussing mappings to LDAP and such, might it be
worthwhile to also discuss the base data format? I've heard that some
folks might be interested in or at least open to using, say, vCard4.
At the least, it might be good to explore our options even if we end
up using the current format.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Leif Johansson <[email-masked]>
Date: Tue, 28 Aug 2012 19:50:26 +0200

On 08/28/2012 05:18 PM, Peter Saint-Andre wrote:
> worthwhile to also discuss the base data format? I've heard that
> some folks might be interested in or at least open to using, say,
> vCard4. At the least, it might be good to explore our options even
> if we end up using the current format.
> 
You're talking about the object schema (persons, groups, etc) right?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 11:54:38 -0600

On 8/28/12 11:50 AM, Leif Johansson wrote:
>> some folks might be interested in or at least open to using,
>> say, vCard4. At the least, it might be good to explore our
>> options even if we end up using the current format.
> 

Yes, sorry about the lack of clarity -- too much multitasking!

/psa

---

From: Leif Johansson <[email-masked]>
Date: Tue, 28 Aug 2012 20:04:11 +0200

On 08/28/2012 07:54 PM, Peter Saint-Andre wrote:
>>> worthwhile to also discuss the base data format? I've heard
>>> that some folks might be interested in or at least open to
>>> using, say, vCard4. At the least, it might be good to explore
>>> our options even if we end up using the current format.
> 

I only ask because some of the threads in Vancouver suggested
a need to finess the framing aswell.

	Cheers Leif

---

From: Likepeng <[email-masked]>
Date: Wed, 29 Aug 2012 00:23:50 +0000

>I've heard that some folks might be interested in or at least open to using, say, vCard4.

Yes, I have interest about the mapping between vCard 4 and the object schema.

I have done some analysis and found out that most of the elements/attributes can be mapped.

I am planing to write an I-D to outline the mappings.

If anybody else has interest, we can work together for this.

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Peter Saint-Andre
发送时间: 2012年8月28日 23:19
收件人: [email-masked]
主题: [scim] data format

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Trey Drake <[email-masked]>
Date: Tue, 28 Aug 2012 19:44:12 -0500

Peter,

Would this be in addition to or in lieu of the JSON and XML formats?

Thanks,
Trey

On Aug 28, 2012, at 10:18 AM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlA84VAACgkQNL8k5A2w/vw9IACfe3R/bDiFKvd6JbXq1+HNA3bH
> LiAAnjUg3ORZs2ARKemNuzRIueLieGKX
> =e7Vh
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 19:17:04 -0600

> Would this be in addition to or in lieu of the JSON and XML

Trey, that is a good question. There's an XML representation for
vCard4 (RFC 6351) and I've contributed to a document defining a JSON
representation (draft-bhat-vcarddav-json), so we could potentially use
those (which seems preferable to defining yet another one-off data
model with both JSON and XML representations). Ideally, I think we'd
settle on just one mandatory-to-implement representation of whatever
data model we choose.

Furthermore, in the terms of RFC 3444 ("On the Difference between
Information Models and Data Models"), we are talking about a data
model here (my use of the word "format" was ill-chosen). In essence,
it seems to me that iNetOrgPerson and vCard4 and SCIM 1.0 share the
same information model (yes, there are some differences, perhaps even
some of significance), but that information model has been mapped to
several different data models.

So I see two separate questions here:

1. Can we use one of the standardized data models (such as
iNetOrgPerson or vCard4, perhaps with extensions as needed)?

2. What representations (e.g., XML or JSON or both or other) do we
want to support, and can we get away with supporting only one?

The reason I asked about vCard4 now is that, if we think we might go
down the path of vCard4 in its JSON representation, then we will want
to coordinate with the VCARDDAV WG (and I will want to put more time
and effort into the I-D I started with my colleague).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Leif Johansson <[email-masked]>
Date: Wed, 29 Aug 2012 09:08:38 +0200

On 08/29/2012 03:17 AM, Peter Saint-Andre wrote:
> vCard4 (RFC 6351) and I've contributed to a document defining a
> JSON representation (draft-bhat-vcarddav-json), so we could
> potentially use those (which seems preferable to defining yet
> another one-off data model with both JSON and XML representations).
> Ideally, I think we'd settle on just one mandatory-to-implement
> representation of whatever data model we choose.

My recollection is that the wg in Vancouver expressed a pretty clear
consensus that it wanted to deprecate the XML representation in favor
of JSON. This will obviously need to be confirmed on the list but it
probably means that if vCard is to be considered that JSON version is
going to be important.

	Cheers Leif

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 29 Aug 2012 11:41:24 +0200

Should we also look att aligning attributes to Windows Azure Active
Directory Graph, or is that a completely different discussion?

regards
//Samuel

On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson <[email-masked]> wrote:
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0
> Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj
> =Niog

---

From: Leif Johansson <[email-masked]>
Date: Wed, 29 Aug 2012 13:54:53 +0200

On 08/29/2012 11:41 AM, Samuel Erdtman wrote:
> Should we also look att aligning attributes to Windows Azure
> Active Directory Graph, or is that a completely different
> discussion?

With my chairs hat on: describe the problem and lets have a discussion
on the list!

	Cheers Leif

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Aug 2012 06:43:12 -0600

On 8/29/12 1:08 AM, Leif Johansson wrote:
>> another one-off data model with both JSON and XML
>> representations). Ideally, I think we'd settle on just one
>> mandatory-to-implement representation of whatever data model we
>> choose.
> 
> My recollection is that the wg in Vancouver expressed a pretty
> clear consensus that it wanted to deprecate the XML representation
> in favor of JSON. This will obviously need to be confirmed on the
> list but it probably means that if vCard is to be considered that
> JSON version is going to be important.

Noted. I've forwarded your message to the chair of the VCARDDAV WG so
he's aware that SCIM folks might have an interest.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 29 Aug 2012 14:42:09 +0000

I'm in favor of only a JSON representation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Wednesday, August 29, 2012 12:09 AM
To: [email-masked]
Subject: Re: [scim] data format

On 08/29/2012 03:17 AM, Peter Saint-Andre wrote:
> model with both JSON and XML representations).

My recollection is that the wg in Vancouver expressed a pretty clear consensus that it wanted to deprecate the XML representation in favor of JSON. This will obviously need to be confirmed on the list but it probably means that if vCard is to be considered that JSON version is going to be important.

	Cheers Leif

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Aug 2012 14:44:29 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Wednesday, August 29, 2012 12:09 AM
To: [email-masked]
Subject: Re: [scim] data format

	Cheers Leif

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 29 Aug 2012 14:44:59 +0000

Not sure I quite understand the issue, I thought the issue would be more around the wire format and API then the attributes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Wednesday, August 29, 2012 2:41 AM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [scim] data format

Should we also look att aligning attributes to Windows Azure Active Directory Graph, or is that a completely different discussion?

regards
//Samuel

On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson <[email-masked]> wrote:
>> representation (draft-bhat-vcarddav-json), so we could potentially 
>> use those (which seems preferable to defining yet another one-off 
>> data model with both JSON and XML representations).

---

From: Leif Johansson <[email-masked]>
Date: Wed, 29 Aug 2012 16:51:44 +0200

On 08/29/2012 04:44 PM, Anthony Nadalin wrote:
> Not sure I quite understand the issue, I thought the issue would be
> more around the wire format and API then the attributes

I would have thought both...

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Aug 2012 14:58:00 +0000

Yes - both the attributes and the wire format are important, which is why the core schema draft provides data models for user, group, and enterprise group.

To achieve some level of interoperability it is important to have a common data model.  This is one of the things that prevented adoption of SPML.

--Kelly

---

From: Trey Drake <[email-masked]>
Date: Wed, 29 Aug 2012 10:01:49 -0500

A discussion on both makes sense though they should be handled separately.  The information model and supported data models ought to be orthogonal to specification of a common set of resources and attributes.  With regards to supported representations I'd be in favor of ditching XML in all forms.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 29 Aug 2012 15:04:07 +0000

You will have to define "data model" to be sure we all understand as in the first sentence both schema and data model are used

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 7:58 AM
To: Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

---

From: Emmanuel Dreux <[email-masked]>
Date: Wed, 29 Aug 2012 15:30:02 +0000

We've tested the Azure Active Directory Graph. It's also restful apis exchanging JSON data.

The schema used by Active Directory Graph uses the standard LDAP attributes names (GivenName, Surname, UserPrincipalName, etc...). 
Schemas are therefore incompatible but it's not complex for implementations to develop a "bridge" that convert one format into the other.
I feel that it does not need to be defined in the specs. It's just a matter of creating an extended user schema that uses LDAP attributes names instead of the SCIM attributes names.

--
Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Anthony Nadalin [mailto:[email-masked]] 
Envoyé : mercredi 29 août 2012 16:45
À : Samuel Erdtman; Leif Johansson
Cc : [email-masked]
Objet : Re: [scim] data format

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Wednesday, August 29, 2012 2:41 AM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [scim] data format

regards
//Samuel

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Aug 2012 16:32:37 +0000

By "data model" I really meant schema (ie - a set of attribute definitions that defines an object).  My point was that (from an interoperability perspective) using a common set of attributes is just as important as getting the wire protocol and API right.

Peter asked: "Can we use one of the standardized data models (such as iNetOrgPerson or vCard4, perhaps with extensions as needed)?"  I think that Samuel's suggestion (if I understood it correctly) was to consider the data models that WAAD Graph API uses for User[1] and Group[2] along with the two that Peter mentioned.

--Kelly

[1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483
[2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 7:58 AM
To: Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 29 Aug 2012 16:43:02 +0000

Yes, and what ever we consider. Lets just do one, to ease interops. And I'm all for making it a JSON only one :)
/ Erik

On Aug 29, 2012, at 6:32 PM, Kelly Grizzle wrote:

> iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu
> s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk
> =c//K

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Aug 2012 16:51:49 +0000

> Can we use one of the standardized data models (such as iNetOrgPerson or vCard4, perhaps with extensions as needed)?

BTW - my answer for this question is that I am all for consistency and avoiding reinventing the wheel.  IMO we should look at inetOrgPerson, vCard4, Graph API users and groups, and any other existing "identity data model" and weigh their merits and short-comings against the current SCIM proposal.

--Kelly

-----Original Message-----
From: Kelly Grizzle 
Sent: Wednesday, August 29, 2012 11:33 AM
To: 'Anthony Nadalin'; Leif Johansson; [email-masked]
Subject: RE: [scim] data format

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 7:58 AM
To: Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 29 Aug 2012 13:51:00 -0400

+1

Igor

---

From: Chris Phillips <[email-masked]>
Date: Wed, 29 Aug 2012 14:44:01 -0400

+1 to Kelly's comments.

A bit of background from previous SCIM schema work by the SCIM group:

A mapping process around SCIM schema happened a few months ago[1] with a
few others.
The exercise was comparing the SCIM schema to other ones with discussion
revolving around what to do about the higher fidelity of SCIM compared to
others.  The approach was to do a hybrid approach and have a high fidelity
SCIM schema(ie. SCIM-to-SCIM transactions) and separate mappings
documented recommending specifics on what to map to other schemas and have
those published as best practices in the SCIM sphere of control.

Given the mention of the other schemas, extending the columns in the
mapping[2] to include Graph API and  vCard4 are just a function of time
and effort.

The reality will be that the first person to map a new schema to SCIM will
set the precedent on the mappings, right or wrong, and is that acceptable
to the spec?  
Will the spec have in scope common mappings to increase the utility of the
spec? Is this in scope of the WG?

With these questions and others in mind, I think it would be useful to
talk about schema principles first and THEN specifics about a given schema
with these principles in mind.  Mindful of course of what is in and out of
scope for SCIM given the slippery slope of sliding into identity
management practice discussions when we are really talking about a spec to
move identity related data around.

>From my perspective, all schemas will have pros and cons (and advocates)
and no one schema will map 100%, so the mapping exercise is practically
inescapable. I would err on the side of leadership on a common set of
mappings that would grow (and age) and would like to hear other opinions.

As a parting thought about the attribute registry[3] and schemas,
certainly the pedigree of an attribute and what schema(s) it appears in
are valuable to track and so would it not in turn be a schema registry? Is
this a better context/home for the schema conversation?

Chris.

[1] https://groups.google.com/group/cloud-directory/msg/e887d8842a1879d1
[2] http://bit.ly/scimmappings
[3] http://tools.ietf.org/id/draft-johansson-areg-reqs-00.html

On 12-08-29 12:51 PM, "Kelly Grizzle" <[email-masked]> wrote:

>> Can we use one of the standardized data models (such as iNetOrgPerson
>>or vCard4, perhaps with extensions as needed)?
>
>BTW - my answer for this question is that I am all for consistency and
>avoiding reinventing the wheel.  IMO we should look at inetOrgPerson,
>vCard4, Graph API users and groups, and any other existing "identity data
>model" and weigh their merits and short-comings against the current SCIM
>proposal.
>
>--Kelly
>
>By "data model" I really meant schema (ie - a set of attribute
>definitions that defines an object).  My point was that (from an
>interoperability perspective) using a common set of attributes is just as
>important as getting the wire protocol and API right.
>
>Peter asked: "Can we use one of the standardized data models (such as
>iNetOrgPerson or vCard4, perhaps with extensions as needed)?"  I think
>that Samuel's suggestion (if I understood it correctly) was to consider
>the data models that WAAD Graph API uses for User[1] and Group[2] along
>with the two that Peter mentioned.
>
>--Kelly
>
>You will have to define "data model" to be sure we all understand as in
>the first sentence both schema and data model are used
>
>Yes - both the attributes and the wire format are important, which is why
>the core schema draft provides data models for user, group, and
>enterprise group.
>
>To achieve some level of interoperability it is important to have a
>common data model.  This is one of the things that prevented adoption of
>SPML.
>
>--Kelly
>
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 29 Aug 2012 19:04:07 +0000

Chris,

It might be useful to setup a means by which the elements of different
sources can be compared side by side.
Then let those who care about a particular mapping fill in the blanks.

If all the others have something that SCIM doesn't, that's a clue.
If all the others don't have something that SCIM has, maybe also a clue.
Look for what is the center of mass, or what hits the most elements for the
buck.
When you reach critical mass (diminishing returns), maybe punt to extension
objects.

Just brainstorming here.
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Phillips
Sent: Wednesday, August 29, 2012 2:44 PM
To: [email-masked]
Subject: Re: [scim] data format

+1 to Kelly's comments.

A mapping process around SCIM schema happened a few months ago[1] with a few
others.
The exercise was comparing the SCIM schema to other ones with discussion
revolving around what to do about the higher fidelity of SCIM compared to
others.  The approach was to do a hybrid approach and have a high fidelity
SCIM schema(ie. SCIM-to-SCIM transactions) and separate mappings documented
recommending specifics on what to map to other schemas and have those
published as best practices in the SCIM sphere of control.

Given the mention of the other schemas, extending the columns in the
mapping[2] to include Graph API and  vCard4 are just a function of time and
effort.

The reality will be that the first person to map a new schema to SCIM will
set the precedent on the mappings, right or wrong, and is that acceptable to
the spec?  
Will the spec have in scope common mappings to increase the utility of the
spec? Is this in scope of the WG?

With these questions and others in mind, I think it would be useful to talk
about schema principles first and THEN specifics about a given schema with
these principles in mind.  Mindful of course of what is in and out of scope
for SCIM given the slippery slope of sliding into identity management
practice discussions when we are really talking about a spec to move
identity related data around.

>From my perspective, all schemas will have pros and cons (and advocates) and
no one schema will map 100%, so the mapping exercise is practically
inescapable. I would err on the side of leadership on a common set of
mappings that would grow (and age) and would like to hear other opinions.

As a parting thought about the attribute registry[3] and schemas, certainly
the pedigree of an attribute and what schema(s) it appears in are valuable
to track and so would it not in turn be a schema registry? Is this a better
context/home for the schema conversation?

Chris.

On 12-08-29 12:51 PM, "Kelly Grizzle" <[email-masked]> wrote:

>vCard4, Graph API users and groups, and any other existing "identity 
>data model" and weigh their merits and short-comings against the 
>current SCIM proposal.
>
>--Kelly
>
>interoperability perspective) using a common set of attributes is just 
>as important as getting the wire protocol and API right.
>
>Yes - both the attributes and the wire format are important, which is 
>why the core schema draft provides data models for user, group, and 
>enterprise group.
>
>common data model.  This is one of the things that prevented adoption 
>of SPML.
>
>--Kelly
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 29 Aug 2012 19:36:11 +0000

Thanks for the clarification as I would have taken the data model to be more of what OData offers and how that is exposed in WAAD then the actual attribute definitions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 9:33 AM
To: Anthony Nadalin; Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 7:58 AM
To: Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Aug 2012 21:14:18 +0000

Sure thing.  FWIW, I think that some of the things that are brought into the Graph API from OData are very nice and warrant some thought within SCIM.  One that is quite interesting to me is a stronger concept of relationships as described in section 4.2 Representing a Navigation Property [1].  My initial opinion (without having delved too deeply into Graph API or OData) is that OData seems like a pretty meaty spec and that SCIM should adopt some of these ideas but try to remain fairly light.

--Kelly

[1] http://www.odata.org/media/30002/OData%20JSON%20Verbose%20Format.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 9:33 AM
To: Anthony Nadalin; Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, August 29, 2012 7:58 AM
To: Leif Johansson; [email-masked]
Subject: Re: [scim] data format

--Kelly

---

From: Trey Drake <[email-masked]>
Date: Wed, 29 Aug 2012 16:36:39 -0500

Perhaps a more fundamental spec to look at w.r.t. linking is Atom/AtomPub (RFC 4287/5023)?    

Thanks,
Trey

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 29 Aug 2012 21:46:15 +0000

LDAP mapping specification is definitely within the charter of the WG and
we have milestones for it. Similarly SAML binding is spelled out in the
charter.

Also during chartering discussion for the WG there was a lot of discussion
on which schema should be used and I believe the consensus was that the WG
should study the various existing standards and decide on the best
solution for SCIM.

Cheers,
Morteza

On 8/29/12 11:44 AM, "Chris Phillips" <[email-masked]> wrote:

>>Kelly Grizzle
>>Leif Johansson