From nobody Mon Nov 3 11:00:25 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4DE1A1BAA for ; Mon, 3 Nov 2014 11:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J4_doMNqU0w for ; Mon, 3 Nov 2014 11:00:17 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA3F1A7023 for ; Mon, 3 Nov 2014 11:00:17 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id a13so5239652igq.11 for ; Mon, 03 Nov 2014 11:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=toZBV21lftRDrshR35LKBMhQ5vKnyG7zOZzOllblvPs=; b=ztrM7Gj8x8zgw/PLiblZJeB9xyx0Qu0r4qiAvYYRrLwGmKcgbl+DB1BNSQRe2+jmgO CXhcJW3BXxVegXslJymCDvHhugx/z09QkltmItUbdlKjxAQYVICwgCiEJlVDmEvXDiXe sjTGJpblbajaAu13LAfJpN19NAs0e6cAhHrHCafsw7GgVR3kj/4m5e5hzKqyEvIwHuDW vRUHfSHHB/oNLDKbgGyuxFAECQTIcaAqdDkElanmqEMsCepKjZA1qbvcxVqO1UwYp+14 a4OSLxBieavyM1/kQDmEmzWF+1qoG9y+uVkjA1QfkDwsQ9oOt7z6ePr98RVIfKJTNLE4 /aRA== MIME-Version: 1.0 X-Received: by 10.107.37.12 with SMTP id l12mr36365674iol.40.1415041216650; Mon, 03 Nov 2014 11:00:16 -0800 (PST) Received: by 10.64.120.225 with HTTP; Mon, 3 Nov 2014 11:00:16 -0800 (PST) In-Reply-To: References: <5446B9D2.8040005@switchresearch.com> <5447C7C1.9000704@switchresearch.com> <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com> Date: Mon, 3 Nov 2014 13:00:16 -0600 Message-ID: From: Shelley To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1141b24e0fa5070506f8f5d7 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/vj5bQRj59L4OoBSlZARw-6KSb8c Cc: Alex Redston , "scim@ietf.org" Subject: Re: [scim] SCIM Attribute Validation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:00:24 -0000 --001a1141b24e0fa5070506f8f5d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The following includes some initial proposed wording to reflect some of these discussions. The text is still somewhat loosely worded so as to not impose strict requirements on consumers or service providers, but to attempt to encourage standardized behavior. Some of the wording has been tweaked slightly, but the primary modifications are represented in green. *2.2 Multi-valued Attributes* > > When returning multi-valued attributes, service providers SHOULD > canonicalize the value returned, if appropriate (e.g. for e-mail addresse= s > and URLs). Service providers MAY return the canonicalized value using the > "display" sub-attribute and return the original value using the "value" > attribute. > > Service providers MAY return the same value more than once with different > types (e.g. the same e-mail address may used for work and home), but SHOU= LD > NOT return the same (type, value) combination more than once per Attribut= e, > as this complicates processing by the Consumer. > > *3.10. HTTP Status and Error Response Handling* > > *invalidValue* > A required value was missing, or the value specified was not compatible > with the operation, attribute type (see Section 2.1 > [I-D.ietf-scim-core-schema]), or schema (see Section 4 > [I-D.ietf-scim-core-schema]) > > *4.1.2. Multi-valued Attributes* > > *phoneNumbers* > Phone numbers for the user. The value SHOULD be specified according to > format in [RFC3966], e.g. 'tel:+1-201-555-0123'. Service providers SHOULD > canonicalize the value according to [RFC3966] format, when appropriate. > The 'display' sub-attribute MAY be used to return the canonicalized > representation of the phone number value. Canonical type values of > "work", "home", "mobile", "fax", "pager", and "other". > > *emails* > E-mail addresses for the user. The value SHOULD be specified according to > [RFC5321]. Service providers SHOULD canonicalize the value according to > [RFC5321], e.g. "B.Jensen@example.com" instead of "B.Jensen@EXAMPLE.COM".= The > 'display' sub-attribute MAY be used to return the canonicalized > representation of the phone number value. Canonical type values of > "work", "home", and "other". > Regarding the canonicalization of RFC 3966 phone numbers into separate "display" and "type" values; e.g. "type":"internal", "display":"7042", "value":"tel:7042;phone-context=3Dinternal" I'd suggest omitting this type of behavior. Canonicalization to RFC 3966 alone should be sufficient, and consumers reading data are welcome to further parse the RFC phone number. Overloading the use of "type" with non-canonical values may add unnecessary complexity to parsing for both SPs and consumers. For example, I'd merely suggest the following type of canonicalizations: Request: "value":"tel:7042;phone-context=3Dinternal" "type":"work" Response: "value":"tel:7042;phone-context=3Dinternal" "display":"tel:7042;phone-context=3Dinternal" "type":"work" Request: "value":"+1 (201) 555-0123" "type":"work" Response: "value":"+1 (201) 555-0123" "display":"tel:+1-201-555-0123" "type":"work" On Wed, Oct 22, 2014 at 2:46 PM, Phil Hunt wrote: > Comments inline=E2=80=A6 > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 22, 2014, at 12:13 PM, Shelley wrote: > > Before any specific text is proposed, I'd like to get a general > understanding for what the agreement/direction is. It seems there are sti= ll > some major open questions that I'd appreciate some input on. > > - Should consumers be required to provide values in specific formats? > - For example, for phone numbers, must consumers provide RFC 3966 > format, an international format, any of multiple common/pre-defined > formats, or is any value allowed? If not in RFC/international forma= t, is > the country/area code assumed? > - Should service providers perform attribute validation or accept any > values? > - If service providers perform validation, what is the expected > behavior when validation fails? (400 / ignore the value / store the= value > as-is?) > - Particularly if there are no requirements for data input and/or no > validation is performed: > - What are the assumptions that service providers can make during > canonicalization? > - What should service providers / consumers do if canonicalization > is not possible? > - Should the use of both the "value" and "display" attributes be > recommended? > > There are minimally two major variations of possible changes on the table= , > with various flavors in between: > > - Require consumers to provide values in specified formats and SPs > perform validation, rejecting invalid values > - SCIM serves as a repository of well-formed, valid data. This > results in the most usable data for SCIM consumers *reading *data, > but puts some burden on SCIM consumers *providing *the data to > conform. > > *-OR-* > > - Allow consumers to provide values in any format, SP performs no > validation though it may *attempt *perform canonicalization > - SCIM serves as a repository of data from third parties, data may not > be consistent, valid, or normalized. This results in the least effo= rt for > SCIM consumers *providing *data, but puts some burden on SCIM > consumers *reading *the data to make sense of the data. > - SCIM SPs may *attempt *to normalize some of the data, but there > may be no guarantees with respect to the consistency or accuracy of= these > normalizations. > > [PH - ] I prefer this because it aligns with Postel=E2=80= =99s Law. > > I recommend stipulating that any modification to the supplied values (e.g= . > canonicalization) by the service providers MUST be reflected in the HTTP > Response JSON representation (e.g. after a POST request). > > I think we also need to be clear about how 3966 ABNF elements should map > to SCIM's multi-valued attribute representation for phoneNumbers. The > earlier suggestion you made is on the right track (mapping to display, > type, value, etc). This might get a bit complex if for example the > telephone number includes embedded parameters *and* the client already > specifies type, value, and display representations. My feeling is that t= he > SP should always honour any assigned =E2=80=9Ctype=E2=80=9D value by the = client. However, > if the client does not assign a =E2=80=9Ctype=E2=80=9D, the SP could assi= gn one based on > parsing parameters. For example, say a client provides a value of " > tel:7042;phone-context=3Dinternal=E2=80=9D. The server might canonicaliz= e/map as: > > =E2=80=9Ctype=E2=80=9D:=E2=80=9Dinternal=E2=80=9D, > =E2=80=9Cdisplay=E2=80=9D:=E2=80=9D7042=E2=80=9D, > =E2=80=9Cvalue=E2=80=9D:"tel:7042;phone-context=3Dinternal=E2=80=9D > > More generically, here is one possible mapping based on the ABNF from > RFC3966 to phoneNumbers attribute: > > =E2=80=9Cvalue=E2=80=9D: =E2=80=9C*{telephone-uri}*=E2=80=9D > =E2=80=9Cdisplay=E2=80=9D:=E2=80=9D{global-number-digits / local-number-d= igits}=E2=80=9D > =E2=80=9Ctype=E2=80=9D:=E2=80=9D{descriptor}=E2=80=9D > > SP=E2=80=99s may attempt to canonicalize =E2=80=9Cvalue=E2=80=9D and norm= alize it. SPs may assign > values to =E2=80=9Cdisplay=E2=80=9D and =E2=80=9Ctype=E2=80=9D if the cli= ent has not asserted values for > these sub-attribues. > > Regarding mapping of context and descriptor to SCIM type, we would be > profiling 3966 to say that the ABNF =E2=80=9Ccontext=E2=80=9D component = is used and > interpreted as a type. (can anybody confirm I have interpreted use of > context in 3966 correctly?) > > > On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt wrote: > >> Shelley, >> >> I think we are pretty much in agreement. Would you mind providing some >> new text for the definition of phoneNumbers? I like where you are going >> with value vs. displayName etc. >> >> It would be good to see how the group feels on a some new proposed text. >> >> Thanks, >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 22, 2014, at 10:22 AM, Shelley wrote: >> >> Thanks for the response, Phil. >> >> If the SP can understand the value, it may accept it. >>> >> >> Right, but what values can/should SPs attempt to "understand" since thes= e >> aren't described in the spec? What assumptions, if any, can be made abou= t >> the format provided by consumers? Further, what happens if the SP doesn'= t >> "accept" the value: 400 response? value is silently ignored? value is >> stored, but not canonicalized? >> >> Further it may modify the value to conform to RFC3966 and return the >>> modified value in the HTTP response. >> >> >> The problem here is that modifying the value is not always possible or >> may be done incorrectly depending on the format provided by the consumer= . >> >> Many service providers would rather accept the POST and simply ignore th= e >>> value than to loose the transaction. >>> >> >> Silently ignoring unknown values seems a bit dangerous as well. I agree >> that the corrective action may be difficult to determine automatically i= f >> the transaction fails fast, but at least it brings some form of visibili= ty >> to the problem. >> >> >> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt wrote= : >> >>> Shelley, >>> >>> Thanks for your comments and bringing this to the groups attention. >>> >>> Overall, I would like to strike a balance in favour of being flexible i= n >>> what is accepted. If the SP can understand the value, it may accept it= . >>> Further it may modify the value to conform to RFC3966 and return the >>> modified value in the HTTP response. For example a service provider >>> should feel free to correct something in telephone-subscriber format to= be >>> returned as a URI instead. >>> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles = of SCIM that we >>> should make more clearer? >>> >>> I think one of the problems with 3966 is that it seems quite broadly >>> defined. Enforcement may be quite valid. But will it improve quality of >>> information given the complication it will cause for clients (e.g. when= a >>> request fails due to format, what is the corrective action)? Many serv= ice >>> providers would rather accept the POST and simply ignore the value than= to >>> loose the transaction. >>> >>> I agree we should adjust the language a bit. For example, are we >>> expecting a telephone-uri or a telephone-subscriber as the value? The = spec >>> is not clear. >>> >>> There are also some other parts to 3966 which duplicate what we are >>> doing in multi-valued attributes. For example the ABNF =E2=80=9Cparamet= er=E2=80=9D enables >>> the following example: >>> tel:7042;phone-context=3Dexample.com >>> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplicat= ive of the >>> function of =E2=80=9Ctype=E2=80=9D. >>> >>> Maybe it is not only that we want to following RFC3966, but we actually >>> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi= -valued JSON >>> structure? >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> On Oct 22, 2014, at 8:41 AM, Shelley wrote: >>> >>> I'd also like to clarify/highlight this problem/challenge with the >>> current SCIM specification - the spec recommends that service providers >>> canonicalize phone numbers to RFC 3966, yet, if there are no requiremen= ts >>> for the data provided by the consumer, this may be impossible. >>> >>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone >>> number" to RFC 3966? In an incomplete scenario, how can an SP canonical= ize >>> "222-2222" without a country/area code? And in an ambiguous scenario, h= ow >>> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an >>> extension)? >>> >>> While it may be possible for the SP to canonicalize *some *values under >>> some *assumptions *(e.g. country code may be assumed, and assumptions >>> based on patterns, etc), it is still possible that the canonicalization >>> would be incorrect and in some cases, impossible. >>> >>> How are other SPs handling this? Is anyone doing validation or >>> canonicalization? >>> >>> Likewise, how are SCIM clients consuming phone numbers (especially thos= e >>> that may be read-only consumers of data and don't have visibility/contr= ol >>> over the source data)? Is anyone doing any normalizing, validating, >>> canonicalizing, or just leaving the data as-is regardless of the >>> format/validity? >>> >>> >>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston < >>> aredston@switchresearch.com> wrote: >>> >>>> Thanks - interesting link. >>>> >>>> Alex Redston >>>> >>>> CEO >>>> Switch Identity Governance Ltd >>>> 07973 320 795 >>>> 020 3434 3888 >>>> >>>> On 22/10/2014 15:50, Shelley wrote: >>>> >>>> The simplest approach would be to require SCIM consumers to provide >>>> phone numbers in the RFC 3966 format, which at least helps to guarante= e the >>>> validity of the format and canonicalizes it into a standard global for= mat >>>> consumable by both external systems and users. This also accounts for = some >>>> of the scenarios you mentioned, such as sip calls. >>>> >>>> As far as validating whether the phone number is actually a >>>> potentially valid number (based on country, area code, etc.), this can= be >>>> discussed further/separately as well. I agree that validating whether = a >>>> phone number is actually in service is probably not feasible but there= are >>>> some standards and libraries that *could *potentially be used to deter >>>> completely bogus numbers [1], but the value in this may be debatable. >>>> >>>> The overall problem is just that without centralized data validation >>>> in the service, SCIM consumers cannot rely on the syntax/validity of t= he >>>> data and therefore the burden of validating and normalizing falls to t= hem. >>>> >>>> [1] https://code.google.com/p/libphonenumber/ >>>> >>>> >>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston < >>>> aredston@switchresearch.com> wrote: >>>> >>>>> Of course the challenge here comes down to the extent to which that >>>>> particular data can be standardised and validated. Taking phone numbe= rs as >>>>> the example you have sip calls, invalid numbers, country specific >>>>> shortcodes, this is potentially a minefield. >>>>> >>>>> Well formed and valid values are two distinct concepts and with >>>>> multiple carrier technologies the anatomy of simple +4412345678901 st= yle >>>>> numbers is no longer fit for purpose. For this reason I do not think = that >>>>> it is feasible for this particular data type to be rejected as bad da= ta >>>>> because the only way to know if a phone number is valid is to dial it= . >>>>> >>>>> What do you think? >>>>> >>>>> Alex >>>>> >>>>> Alex Redston >>>>> >>>>> CEO >>>>> Switch Identity Governance Ltd >>>>> 07973 320 795 >>>>> 020 3434 3888 >>>>> >>>>> On 21/10/2014 20:36, Shelley wrote: >>>>> >>>>> The SCIM specification expects service providers should be able to >>>>> canonicalize provided data into a common format (e.g. RFC 3966 for >>>>> phoneNumbers), yet it does not explicitly describe input requirements >>>>> or validation for attributes such as these.* Is it expected that >>>>> values that cannot accurately be canonicalized are rejected by the SC= IM >>>>> service or that the SCIM service accepts this invalid data and merely >>>>> persists and returns this bad data to consumers?* >>>>> >>>>> As a SCIM Service Provider, we are currently performing validation on >>>>> attributes such as phoneNumbers and emails to ensure that they >>>>> contain well-formed, valid values, and returning a 400 with a descrip= tion >>>>> of the error if validation fails. One of the benefits of SCIM is that= data >>>>> may come from multiple sources and may be consumed by multiple client= s, and >>>>> SCIM provides a repository of structured and well-formed data so that >>>>> consumers can reliably derive meaning and use from this data. Without >>>>> attribute validation and a guarantee of canonicalized values, this go= al >>>>> does not seem feasible and puts the burden on consumers to make sense= of >>>>> potentially invalid data. >>>>> >>>>> The downside to attribute validation is that it requires the SCIM >>>>> consumers sending data to ensure valid data as well. As these consume= rs are >>>>> closest to the source data, though, this seems like the most reasonab= le >>>>> approach rather than putting the burden on the service provider and/o= r >>>>> other SCIM consumers to make sense of the data. Aside from just "bad = data" >>>>> (e.g. sending "not a phone number" or "000-0000" for a phone number),= for >>>>> example, if the SCIM consumer sending source data sends phone numbers >>>>> without area codes or sends only internal extensions, another SCIM co= nsumer >>>>> may not be able to make sense of this data. It seems reasonable to re= quire >>>>> the consumer sending the data to ensure that this data is well-formed= and >>>>> canonicalized/canonicalizable. >>>>> >>>>> A *good *example in the SCIM specification is the country attribute, >>>>> which clearly indicates the attribute's requirements. A *bad *example >>>>> is the phoneNumbers attribute, which doesn't describe the expected >>>>> format to be provided by consumers, yet recommends that the service >>>>> provider canonicalize the value even though the input may not be able= to be >>>>> canonicalized. >>>>> >>>>> I'd be interested in hearing others' opinions on this matter, and >>>>> whether the SCIM specification should clarify further restrictions on >>>>> attribute values. >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> >>>>> This email is free from viruses and malware because avast! Antivirus >>>>> protection is active. >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> This email is free from viruses and malware because avast! Antivirus >>>> protection is active. >>>> >>>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >>> >> >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --001a1141b24e0fa5070506f8f5d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The following includes some initial proposed wor= ding to reflect some of these discussions.

The text is still s= omewhat loosely worded so as to not impose strict requirements on consumers= or service providers, but to attempt to encourage standardized behavior. S= ome of the wording has been tweaked slightly, but the primary modifications= are represented in green.
<= /div>

<= b>2.2 Multi-valued Attributes

When returning multi-valued attrib= utes, service providers SHOULD canonicalize the value returned, if appropri= ate (e.g. for e-mail addresses and URLs). Service providers MAY return the canonicalized value using the "di= splay" sub-attribute and return the original value using the "val= ue" attribute.

Service providers MAY return the same val= ue more than once with different types (e.g. the same e-mail address may us= ed for work and home), but SHOULD NOT return the same (type, value) combina= tion more than once per Attribute, as this complicates processing by the Co= nsumer.

3.10. HTTP Status and Error Response Handling

= invalidValue
A required value was missing, or the value specified= was not compatible with the operation, attribute type (see Section 2.1 [I-= D.ietf-scim-core-schema]), or schema (= see Section 4 [I-D.ietf-scim-core-schema])

4.1.2. Multi-va= lued Attributes

phoneNumbers
Phone numbers for the use= r. The value SHOULD be specified accor= ding to format in [RFC3966], e.g. 'tel:+1-201-555-0123'. Ser= vice providers SHOULD canonicalize the value according to [RFC3966] format<= span style=3D"color:rgb(56,118,29)">, when appropriate. The 'display= 9; sub-attribute MAY be used to return the canonicalized representation of = the phone number value. Canonical type values of "work", &= quot;home", "mobile", "fax", "pager", an= d "other".

emails
E-mail addresses for the user.= The value SHOULD be specified accordi= ng to [RFC5321]. Service providers SHOULD canonicalize the value acc= ording to [RFC5321], e.g. "B.Jensen@example.com" instea= d of "B.Jensen@EXAMPLE.COM". The 'display' sub-attribute MAY be used to return the ca= nonicalized representation of the phone number value. Canonical type= values of "work", "home", and "other".


Regarding the canonicalization of RFC 39= 66 phone numbers into separate "display" and "type" val= ues; e.g.

"type":"<= /span>internal",
"display":"7042",<= /div>
"value= ":"tel:7042;phone-context=3Dinternal= "=

I'd suggest o= mitting this type of behavior. Canonicalization to RFC 3966 alone should be= sufficient, and consumers reading data are welcome to further parse the RF= C phone number. Overloading the use of "type" with non-canonical = values may add unnecessary complexity to parsing for both SPs and consumers= .

For example, I'd merely suggest the following type = of canonicalizations:

Request:
"value":= "tel:7042;phone= -context=3Dinternal"
"type<= span style=3D"font-family:courier new,monospace">":"work"

Response:=
"value":"tel:7042;phone-context=3Dinternal"
"display":"tel:7= 042;phone-context=3Dinternal"
<= span style=3D"font-family:courier new,monospace">"type":"work"

= Request:
"value":"+1 (201) 555-0123"
"type&q= uot;:"wo= rk"

Resp= onse:
"value":"+1 (201) 555-0123= "
"display= ":"= tel:+1-201-555-0123<= span style=3D"font-size:13px;line-height:15px">"<= br>&= quot;type":"work"
=C2=A0
<= /div>

On Wed, Oct = 22, 2014 at 2:46 PM, Phil Hunt <phil.hunt@oracle.com> wro= te:
C= omments inline=E2=80=A6


On Oct 22, 2014, at 12:13 PM, Shelley <randomshelley@gm= ail.com> wrote:

= Before any specific text is proposed, I'd like to get a general underst= anding for what the agreement/direction is. It seems there are still some m= ajor open questions that I'd appreciate some input on.
  • Shoul= d consumers be required to provide values in specific formats?
    • = For example, for phone numbers, must consumers provide RFC 3966 format, an = international format, any of multiple common/pre-defined formats, or is any= value allowed? If not in RFC/international format, is the country/area cod= e assumed?
  • Should service providers perform attribute validati= on or accept any values?
    • If service providers perform validatio= n, what is the expected behavior when validation fails? (400 / ignore the v= alue / store the value as-is?)
  • Particularly if there are no re= quirements for data input and/or no validation is performed:
    • Wh= at are the assumptions that service providers can make during canonicalizat= ion?
    • What should service providers / consumers do if canonicalizati= on is not possible?
    • Should the use of both the "value" an= d "display" attributes be recommended?

There are= minimally two major variations of possible changes on the table, with vari= ous flavors in between:

  • Require consumers to provide values in s= pecified formats and SPs perform validation, rejecting invalid values
    • <= ul>
  • SCIM serves as a repository of well-formed, valid data. This results= in the most usable data for SCIM consumers reading data, but puts s= ome burden on SCIM consumers providing the data to conform.
    • =
-OR-
  • Allo= w consumers to provide values in any format, SP performs no validation thou= gh it may attempt perform canonicalization
    • SCIM serv= es as a repository of data from third parties, data may not be consistent, = valid, or normalized. This results in the least effort for SCIM consumers <= i>providing data, but puts some burden on SCIM consumers reading the data to make sense of the data.
    • SCIM SPs may attempt to= normalize some of the data, but there may be no guarantees with respect to= the consistency or accuracy of these normalizations.
[PH - <individualHat/>] I prefer this because = it aligns with Postel=E2=80=99s Law.

I recommend s= tipulating that any modification to the supplied values (e.g. canonicalizat= ion) by the service providers MUST be reflected in the HTTP Response JSON r= epresentation (e.g. after a POST request).=C2=A0

I= think we also need to be clear about how 3966 ABNF elements should map to = SCIM's multi-valued attribute representation for phoneNumbers. The earl= ier suggestion you made is on the right track (mapping to display, type, va= lue, etc).=C2=A0 This might get a bit complex if for example the telephone = number includes embedded parameters *and* the client already specifies type= , value, and display representations.=C2=A0 My feeling is that the SP shoul= d always honour any assigned =E2=80=9Ctype=E2=80=9D value by the client.=C2= =A0 However, if the client does not assign a =E2=80=9Ctype=E2=80=9D, the SP= could assign one based on parsing parameters. For example, say a client pr= ovides a value of "te= l:7042;phone-context=3Dinternal=E2=80=9D.=C2=A0 The server might canonicalize/map as:

=E2=80=9Ctype=E2=80=9D:=E2=80=9Dinternal=E2=80=9D,
=E2=80=9Cdisplay=E2=80=9D:=E2=80=9D7042=E2=80=9D,
=
=E2=80=9Cvalue=E2=80= =9D:"tel:7042;p= hone-context=3Dinternal=E2=80=9D

More generically, here is one possible mapping based on t= he ABNF from RFC3966 to phoneNumbers attribute:

=E2=80=9Cvalue=E2=80=9D:=C2=A0=E2=80=9C= {telephone-uri}=E2=80=9D
=E2=80=9Cdisplay=E2=80=9D:=E2=80=9D{global-number-digits= / local-number-digits}=E2=80=9D
=E2=80=9Ctype=E2=80=9D:=E2=80=9D{descriptor}=E2=80= =9D

SP=E2=80=99= s may attempt to canonicalize=C2=A0=E2=80=9Cvalue=E2=80=9D and normalize it= . SPs may assign values to=C2=A0=E2=80=9Cdisplay=E2=80=9D and=C2=A0=E2=80= =9Ctype=E2=80=9D if the client has not asserted values for these sub-attrib= ues.

<= /span>
Regarding = mapping of context and descriptor to SCIM type, we would be profiling 3966 = to say that the ABNF =C2=A0=E2=80=9Ccontext=E2=80=9D component is used and = interpreted as a type. (can anybody confirm I have interpreted use of conte= xt in 3966 correctly?)


On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:
Shelley,

I think we are pretty much in agr= eement. Would you mind providing some new text for the definition of phoneN= umbers?=C2=A0 I like where you are going with value vs. displayName etc.

It would be good to see how the group feels on a som= e new proposed text.

Thanks,


On Oct 22, 2014, at 10:22 AM, Shelley <randomshelley@gmail.com> w= rote:

Thanks for t= he response, Phil.

=C2=A0If the SP can understand the value, it may accept it.

Right, but what values can/should SPs attempt to "understa= nd" since these aren't described in the spec? What assumptions, if= any, can be made about the format provided by consumers? Further, what hap= pens if the SP doesn't "accept" the value: 400 response? valu= e is silently ignored? value is stored, but not canonicalized?

=
Further it may modify the= value to conform to RFC3966 and return the modified value in the HTTP resp= onse.

The problem here is that modifying th= e value is not always possible or may be done incorrectly depending on the = format provided by the consumer.

Many service providers would rather accept the POST and si= mply ignore the value than to loose the transaction.

Silently ignoring unknown values seems a bit dangerous as well. I = agree that the corrective action may be difficult to determine automaticall= y if the transaction fails fast, but at least it brings some form of visibi= lity to the problem.
=C2=A0

On Wed, Oct 22, 2014 at 11:= 39 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Shelley,

Thanks for your comments and bringing this to the g= roups attention.

Overall, I would like to strike a bala= nce in favour of being flexible in what is accepted.=C2=A0 If the SP can un= derstand the value, it may accept it. Further it may modify the value to co= nform to RFC3966 and return the modified value in the HTTP response. For example a service provider should feel free to correct something in tel= ephone-subscriber format to be returned as a URI instead.
=E2=80= =94> maybe Postel=E2=80=99s Law is one of the general principles of SCIM= that we should make more clearer?

I think one of th= e problems with 3966 is that it seems quite broadly defined. Enforcement ma= y be quite valid. But will it improve quality of information given the comp= lication it will cause for clients (e.g. when a request fails due to format= , what is the corrective action)?=C2=A0 Many service providers would rather= accept the POST and simply ignore the value than to loose the transaction.=

I agree we should adjust the languag= e a bit. For example, are we expecting a telephone-uri or a telephone-subsc= riber as the value?=C2=A0 The spec is not clear. =C2=A0

There are also some other parts to 3966 which duplicate what we are d= oing in multi-valued attributes. For example the ABNF =E2=80=9Cparameter=E2= =80=9D enables the following example:=C2=A0
=C2=A0=C2=A0tel:7042;ph= one-context=3Dexample.com=
In this case, =E2=80=9Cphone-context=E2=80=9D could b= e seen as duplicative of the function of =E2=80=9Ctype=E2=80=9D.
=
Maybe it is not only that we want to following RFC3966, but = we actually want to fully specify how 3966 is mapped to phoneNumber=E2=80= =99s multi-valued JSON structure?

Phil

@independentid=
phil.hunt@oracle.com

=


On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com&g= t; wrote:

I'd also like to clarify/highlight this problem/challenge = with the current SCIM specification - the spec recommends that service prov= iders canonicalize phone numbers to RFC 3966, yet, if there are no requirem= ents for the data provided by the consumer, this may be impossible.

= In the extreme scenario, how can a SCIM SP canonicalize "not a phone n= umber" to RFC 3966? In an incomplete scenario, how can an SP canonical= ize "222-2222" without a country/area code? And in an ambiguous s= cenario, how can an SP canonicalize "201-5399 123" (where 123 is = assumed to be an extension)?

While it may be possible for the = SP to canonicalize some values under some assumptions (e.g. c= ountry code may be assumed, and assumptions based on patterns, etc), it is = still possible that the canonicalization would be incorrect and in some cas= es, impossible.

How are other SPs handling this? Is anyone doi= ng validation or canonicalization?

Likewise, how are SCIM cli= ents consuming phone numbers (especially those that may be read-only consum= ers of data and don't have visibility/control over the source data)? Is= anyone doing any normalizing, validating, canonicalizing, or just leaving = the data as-is regardless of the format/validity?

<= div class=3D"gmail_extra">
On Wed, Oct 22, 20= 14 at 10:05 AM, Alex Redston <aredston@switchresearch.com>= ; wrote:
=20 =20 =20
Thanks - interesting link.
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888
On 22/10/2014 15:50, Shelley wrote:
The simplest approach would be to require SCIM consumers to provide phone numbers in the RFC 3966 format, which at least helps to guarantee the validity of the format and canonicalizes it into a standard global format consumable by both external systems and users. This also accounts for some of the scenarios you mentioned, such as sip calls.

As far as validating whether the phone number is actually a potentially valid number (based on country, area code, etc.), this can be discussed further/separately as well. I agree that validating whether a phone number is actually in service is probably not feasible but there are some standards and libraries that could potentially be used to deter completely bogus numbers [1], but the value in this may be debatable.

The overall problem is just that without centralized data validation in the service, SCIM consumers cannot rely on the syntax/validity of the data and therefore the burden of validating and normalizing falls to them.

[1] https://code.google.com/p/libphonenumber/


On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <aredston@switchresearch.com><= /span> wrote:
Of course the challenge here comes down to the extent to which that particular data can be standardised and validated. Taking phone numbers as the example you have sip calls, invalid numbers, country specific shortcodes, this is potentially a minefield.

Well formed and valid values are two distinct concepts and with multiple carrier technologies the anatomy of simple +4412345678901 style numbers is no longer fit for purpose. For this reason I do not think that it is feasible for this particular data type to be rejected as bad data because the only way to know if a phone number is valid is to dial it.

What do you think?

Alex
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888
On 21/10/2014 20:36, Shelley wrote:
The SCIM specification expects service providers should be able to canonicalize provided data into a common format (e.g. RFC 3966 for phoneNumbers), yet it does not explicitly describe input requirements or validation for attributes such as these. Is it expected that values that cannot accurately be canonicalized are rejected by the SCIM service or that the SCIM service accepts this invalid data and merely persists and returns this bad data to consumers?

As a SCIM Service Provider, we are currently performing validation on attributes such as phoneNumbers and country attribute, which clearly indicates the attribute's requirements. A bad = example is the phoneNumbers attribute, which doesn't describe the expected format to be provided by consumers, yet recommends that the service provider canonicalize the value even though the input may not be able to be canonicalized.

I'd be interested in hearing others' opin= ions on this matter, and whether the SCIM specification should clarify further restrictions on attribute values.



This email is free from viruses and malware because avast! Antivirus protection is active.




=20

This email is free from viruses and malware because avast! Antivirus protection is active.



_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim




_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim


--001a1141b24e0fa5070506f8f5d7-- From nobody Mon Nov 3 11:34:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3311A7031 for ; Mon, 3 Nov 2014 11:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z77eV9uLOlyi for ; Mon, 3 Nov 2014 11:34:24 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E571A00D7 for ; Mon, 3 Nov 2014 11:34:24 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sA3JYMlX014756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Nov 2014 19:34:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA3JYLbc005389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Nov 2014 19:34:22 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA3JYLof005378; Mon, 3 Nov 2014 19:34:21 GMT Received: from [192.168.1.8] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2014 11:34:13 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B6B369-17B5-479A-90F0-88B82802E717" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 3 Nov 2014 11:33:53 -0800 Message-Id: <94ACBA87-D7BB-4E48-AFD6-BCEA64A1BFB9@oracle.com> References: <5446B9D2.8040005@switchresearch.com> <5447C7C1.9000704@switchresearch.com> <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com> To: Shelley X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aSxQHYZuNXz-y0VXEh9u-fCrlAE Cc: Alex Redston , "scim@ietf.org" Subject: Re: [scim] SCIM Attribute Validation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:34:30 -0000 --Apple-Mail=_C2B6B369-17B5-479A-90F0-88B82802E717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Shelley, Thanks for putting this together. I suggest folks take a look.=20 FYI...These issues were raised by Shelley during the WGLC process. Phil @independentid www.independentid.com phil.hunt@oracle.com On Nov 3, 2014, at 11:00 AM, Shelley wrote: > The following includes some initial proposed wording to reflect some = of these discussions. >=20 > The text is still somewhat loosely worded so as to not impose strict = requirements on consumers or service providers, but to attempt to = encourage standardized behavior. Some of the wording has been tweaked = slightly, but the primary modifications are represented in green. >=20 > 2.2 Multi-valued Attributes >=20 > When returning multi-valued attributes, service providers SHOULD = canonicalize the value returned, if appropriate (e.g. for e-mail = addresses and URLs). Service providers MAY return the canonicalized = value using the "display" sub-attribute and return the original value = using the "value" attribute. >=20 > Service providers MAY return the same value more than once with = different types (e.g. the same e-mail address may used for work and = home), but SHOULD NOT return the same (type, value) combination more = than once per Attribute, as this complicates processing by the Consumer. >=20 > 3.10. HTTP Status and Error Response Handling >=20 > invalidValue > A required value was missing, or the value specified was not = compatible with the operation, attribute type (see Section 2.1 = [I-D.ietf-scim-core-schema]), or schema (see Section 4 = [I-D.ietf-scim-core-schema]) >=20 > 4.1.2. Multi-valued Attributes >=20 > phoneNumbers > Phone numbers for the user. The value SHOULD be specified according to = format in [RFC3966], e.g. 'tel:+1-201-555-0123'. Service providers = SHOULD canonicalize the value according to [RFC3966] format, when = appropriate. The 'display' sub-attribute MAY be used to return the = canonicalized representation of the phone number value. Canonical type = values of "work", "home", "mobile", "fax", "pager", and "other". >=20 > emails > E-mail addresses for the user. The value SHOULD be specified according = to [RFC5321]. Service providers SHOULD canonicalize the value according = to [RFC5321], e.g. "B.Jensen@example.com" instead of = "B.Jensen@EXAMPLE.COM". The 'display' sub-attribute MAY be used to = return the canonicalized representation of the phone number value. = Canonical type values of "work", "home", and "other". >=20 >=20 > Regarding the canonicalization of RFC 3966 phone numbers into separate = "display" and "type" values; e.g. >=20 > "type":"internal", > "display":"7042", > "value":"tel:7042;phone-context=3Dinternal" >=20 > I'd suggest omitting this type of behavior. Canonicalization to RFC = 3966 alone should be sufficient, and consumers reading data are welcome = to further parse the RFC phone number. Overloading the use of "type" = with non-canonical values may add unnecessary complexity to parsing for = both SPs and consumers. >=20 > For example, I'd merely suggest the following type of = canonicalizations: >=20 > Request: > "value":"tel:7042;phone-context=3Dinternal" > "type":"work" >=20 > Response: > "value":"tel:7042;phone-context=3Dinternal" > "display":"tel:7042;phone-context=3Dinternal" > "type":"work" >=20 > Request: > "value":"+1 (201) 555-0123" > "type":"work" >=20 > Response: > "value":"+1 (201) 555-0123" > "display":"tel:+1-201-555-0123" > "type":"work" > =20 >=20 > On Wed, Oct 22, 2014 at 2:46 PM, Phil Hunt = wrote: > Comments inline=85 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 22, 2014, at 12:13 PM, Shelley wrote: >=20 >> Before any specific text is proposed, I'd like to get a general = understanding for what the agreement/direction is. It seems there are = still some major open questions that I'd appreciate some input on. >> Should consumers be required to provide values in specific formats? >> For example, for phone numbers, must consumers provide RFC 3966 = format, an international format, any of multiple common/pre-defined = formats, or is any value allowed? If not in RFC/international format, is = the country/area code assumed? >> Should service providers perform attribute validation or accept any = values? >> If service providers perform validation, what is the expected = behavior when validation fails? (400 / ignore the value / store the = value as-is?) >> Particularly if there are no requirements for data input and/or no = validation is performed: >> What are the assumptions that service providers can make during = canonicalization? >> What should service providers / consumers do if canonicalization is = not possible? >> Should the use of both the "value" and "display" attributes be = recommended? >> There are minimally two major variations of possible changes on the = table, with various flavors in between: >>=20 >> Require consumers to provide values in specified formats and SPs = perform validation, rejecting invalid values >> SCIM serves as a repository of well-formed, valid data. This results = in the most usable data for SCIM consumers reading data, but puts some = burden on SCIM consumers providing the data to conform. >> -OR- >> Allow consumers to provide values in any format, SP performs no = validation though it may attempt perform canonicalization >> SCIM serves as a repository of data from third parties, data may not = be consistent, valid, or normalized. This results in the least effort = for SCIM consumers providing data, but puts some burden on SCIM = consumers reading the data to make sense of the data. >> SCIM SPs may attempt to normalize some of the data, but there may be = no guarantees with respect to the consistency or accuracy of these = normalizations. > [PH - ] I prefer this because it aligns with Postel=92s = Law. >=20 > I recommend stipulating that any modification to the supplied values = (e.g. canonicalization) by the service providers MUST be reflected in = the HTTP Response JSON representation (e.g. after a POST request).=20 >=20 > I think we also need to be clear about how 3966 ABNF elements should = map to SCIM's multi-valued attribute representation for phoneNumbers. = The earlier suggestion you made is on the right track (mapping to = display, type, value, etc). This might get a bit complex if for example = the telephone number includes embedded parameters *and* the client = already specifies type, value, and display representations. My feeling = is that the SP should always honour any assigned =93type=94 value by the = client. However, if the client does not assign a =93type=94, the SP = could assign one based on parsing parameters. For example, say a client = provides a value of "tel:7042;phone-context=3Dinternal=94. The server = might canonicalize/map as: >=20 > =93type=94:=94internal=94, > =93display=94:=947042=94, > =93value=94:"tel:7042;phone-context=3Dinternal=94 >=20 > More generically, here is one possible mapping based on the ABNF from = RFC3966 to phoneNumbers attribute: >=20 > =93value=94: =93{telephone-uri}=94 > =93display=94:=94{global-number-digits / local-number-digits}=94 > =93type=94:=94{descriptor}=94 >=20 > SP=92s may attempt to canonicalize =93value=94 and normalize it. SPs = may assign values to =93display=94 and =93type=94 if the client has not = asserted values for these sub-attribues. >=20 > Regarding mapping of context and descriptor to SCIM type, we would be = profiling 3966 to say that the ABNF =93context=94 component is used and = interpreted as a type. (can anybody confirm I have interpreted use of = context in 3966 correctly?) >=20 >>=20 >> On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt = wrote: >> Shelley, >>=20 >> I think we are pretty much in agreement. Would you mind providing = some new text for the definition of phoneNumbers? I like where you are = going with value vs. displayName etc. >>=20 >> It would be good to see how the group feels on a some new proposed = text. >>=20 >> Thanks, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Oct 22, 2014, at 10:22 AM, Shelley = wrote: >>=20 >>> Thanks for the response, Phil. >>>=20 >>> If the SP can understand the value, it may accept it. >>>=20 >>> Right, but what values can/should SPs attempt to "understand" since = these aren't described in the spec? What assumptions, if any, can be = made about the format provided by consumers? Further, what happens if = the SP doesn't "accept" the value: 400 response? value is silently = ignored? value is stored, but not canonicalized? >>>=20 >>> Further it may modify the value to conform to RFC3966 and return the = modified value in the HTTP response. >>>=20 >>> The problem here is that modifying the value is not always possible = or may be done incorrectly depending on the format provided by the = consumer. >>>=20 >>> Many service providers would rather accept the POST and simply = ignore the value than to loose the transaction. >>>=20 >>> Silently ignoring unknown values seems a bit dangerous as well. I = agree that the corrective action may be difficult to determine = automatically if the transaction fails fast, but at least it brings some = form of visibility to the problem. >>> =20 >>>=20 >>> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt = wrote: >>> Shelley, >>>=20 >>> Thanks for your comments and bringing this to the groups attention. >>>=20 >>> Overall, I would like to strike a balance in favour of being = flexible in what is accepted. If the SP can understand the value, it = may accept it. Further it may modify the value to conform to RFC3966 and = return the modified value in the HTTP response. For example a service = provider should feel free to correct something in telephone-subscriber = format to be returned as a URI instead. >>> =97> maybe Postel=92s Law is one of the general principles of SCIM = that we should make more clearer? >>>=20 >>> I think one of the problems with 3966 is that it seems quite broadly = defined. Enforcement may be quite valid. But will it improve quality of = information given the complication it will cause for clients (e.g. when = a request fails due to format, what is the corrective action)? Many = service providers would rather accept the POST and simply ignore the = value than to loose the transaction. >>>=20 >>> I agree we should adjust the language a bit. For example, are we = expecting a telephone-uri or a telephone-subscriber as the value? The = spec is not clear. =20 >>>=20 >>> There are also some other parts to 3966 which duplicate what we are = doing in multi-valued attributes. For example the ABNF =93parameter=94 = enables the following example:=20 >>> tel:7042;phone-context=3Dexample.com >>> In this case, =93phone-context=94 could be seen as duplicative of = the function of =93type=94. >>>=20 >>> Maybe it is not only that we want to following RFC3966, but we = actually want to fully specify how 3966 is mapped to phoneNumber=92s = multi-valued JSON structure? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Oct 22, 2014, at 8:41 AM, Shelley = wrote: >>>=20 >>>> I'd also like to clarify/highlight this problem/challenge with the = current SCIM specification - the spec recommends that service providers = canonicalize phone numbers to RFC 3966, yet, if there are no = requirements for the data provided by the consumer, this may be = impossible. >>>>=20 >>>> In the extreme scenario, how can a SCIM SP canonicalize "not a = phone number" to RFC 3966? In an incomplete scenario, how can an SP = canonicalize "222-2222" without a country/area code? And in an ambiguous = scenario, how can an SP canonicalize "201-5399 123" (where 123 is = assumed to be an extension)? >>>>=20 >>>> While it may be possible for the SP to canonicalize some values = under some assumptions (e.g. country code may be assumed, and = assumptions based on patterns, etc), it is still possible that the = canonicalization would be incorrect and in some cases, impossible. >>>>=20 >>>> How are other SPs handling this? Is anyone doing validation or = canonicalization?=20 >>>>=20 >>>> Likewise, how are SCIM clients consuming phone numbers (especially = those that may be read-only consumers of data and don't have = visibility/control over the source data)? Is anyone doing any = normalizing, validating, canonicalizing, or just leaving the data as-is = regardless of the format/validity? >>>>=20 >>>>=20 >>>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston = wrote: >>>> Thanks - interesting link. >>>> Alex Redston >>>>=20 >>>> CEO >>>> Switch Identity Governance Ltd >>>> 07973 320 795 >>>> 020 3434 3888 >>>> On 22/10/2014 15:50, Shelley wrote: >>>>> The simplest approach would be to require SCIM consumers to = provide phone numbers in the RFC 3966 format, which at least helps to = guarantee the validity of the format and canonicalizes it into a = standard global format consumable by both external systems and users. = This also accounts for some of the scenarios you mentioned, such as sip = calls. >>>>>=20 >>>>> As far as validating whether the phone number is actually a = potentially valid number (based on country, area code, etc.), this can = be discussed further/separately as well. I agree that validating whether = a phone number is actually in service is probably not feasible but there = are some standards and libraries that could potentially be used to deter = completely bogus numbers [1], but the value in this may be debatable. >>>>>=20 >>>>> The overall problem is just that without centralized data = validation in the service, SCIM consumers cannot rely on the = syntax/validity of the data and therefore the burden of validating and = normalizing falls to them. >>>>>=20 >>>>> [1] https://code.google.com/p/libphonenumber/ >>>>>=20 >>>>>=20 >>>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston = wrote: >>>>> Of course the challenge here comes down to the extent to which = that particular data can be standardised and validated. Taking phone = numbers as the example you have sip calls, invalid numbers, country = specific shortcodes, this is potentially a minefield. >>>>>=20 >>>>> Well formed and valid values are two distinct concepts and with = multiple carrier technologies the anatomy of simple +4412345678901 style = numbers is no longer fit for purpose. For this reason I do not think = that it is feasible for this particular data type to be rejected as bad = data because the only way to know if a phone number is valid is to dial = it. >>>>>=20 >>>>> What do you think? >>>>>=20 >>>>> Alex >>>>> Alex Redston >>>>>=20 >>>>> CEO >>>>> Switch Identity Governance Ltd >>>>> 07973 320 795 >>>>> 020 3434 3888 >>>>> On 21/10/2014 20:36, Shelley wrote: >>>>>> The SCIM specification expects service providers should be able = to canonicalize provided data into a common format (e.g. RFC 3966 for = phoneNumbers), yet it does not explicitly describe input requirements or = validation for attributes such as these. Is it expected that values that = cannot accurately be canonicalized are rejected by the SCIM service or = that the SCIM service accepts this invalid data and merely persists and = returns this bad data to consumers? >>>>>>=20 >>>>>> As a SCIM Service Provider, we are currently performing = validation on attributes such as phoneNumbers and emails to ensure that = they contain well-formed, valid values, and returning a 400 with a = description of the error if validation fails. One of the benefits of = SCIM is that data may come from multiple sources and may be consumed by = multiple clients, and SCIM provides a repository of structured and = well-formed data so that consumers can reliably derive meaning and use = from this data. Without attribute validation and a guarantee of = canonicalized values, this goal does not seem feasible and puts the = burden on consumers to make sense of potentially invalid data. >>>>>>=20 >>>>>> The downside to attribute validation is that it requires the SCIM = consumers sending data to ensure valid data as well. As these consumers = are closest to the source data, though, this seems like the most = reasonable approach rather than putting the burden on the service = provider and/or other SCIM consumers to make sense of the data. Aside = from just "bad data" (e.g. sending "not a phone number" or "000-0000" = for a phone number), for example, if the SCIM consumer sending source = data sends phone numbers without area codes or sends only internal = extensions, another SCIM consumer may not be able to make sense of this = data. It seems reasonable to require the consumer sending the data to = ensure that this data is well-formed and canonicalized/canonicalizable. >>>>>>=20 >>>>>> A good example in the SCIM specification is the country = attribute, which clearly indicates the attribute's requirements. A bad = example is the phoneNumbers attribute, which doesn't describe the = expected format to be provided by consumers, yet recommends that the = service provider canonicalize the value even though the input may not be = able to be canonicalized. >>>>>>=20 >>>>>> I'd be interested in hearing others' opinions on this matter, and = whether the SCIM specification should clarify further restrictions on = attribute values. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =09 >>>>> This email is free from viruses and malware because avast! = Antivirus protection is active.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =09 >>>> This email is free from viruses and malware because avast! = Antivirus protection is active. =09 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_C2B6B369-17B5-479A-90F0-88B82802E717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Shelley,

Thanks for putting this = together. I suggest folks take a = look. 

FYI...These issues were raised by = Shelley during the WGLC process.


On Nov 3, 2014, at 11:00 AM, Shelley <randomshelley@gmail.com> = wrote:

The following includes some = initial proposed wording to reflect some of these = discussions.

The text is still somewhat loosely worded so = as to not impose strict requirements on consumers or service providers, = but to attempt to encourage standardized behavior. Some of the wording = has been tweaked slightly, but the primary modifications are represented = in green.

2.2 = Multi-valued Attributes

When returning multi-valued = attributes, service providers SHOULD canonicalize the value returned, if = appropriate (e.g. for e-mail addresses and URLs). Service providers MAY return the = canonicalized value using the "display" sub-attribute and return the = original value using the "value" attribute.

Service = providers MAY return the same value more than once with different types = (e.g. the same e-mail address may used for work and home), but SHOULD = NOT return the same (type, value) combination more than once per = Attribute, as this complicates processing by the = Consumer.

3.10. HTTP Status and Error Response = Handling

invalidValue
A required value was missing, = or the value specified was not compatible with the operation, attribute = type (see Section 2.1 [I-D.ietf-scim-core-schema]), or schema (see Section 4 = [I-D.ietf-scim-core-schema])

4.1.2. Multi-valued = Attributes

phoneNumbers
Phone numbers for the user. = The value SHOULD be specified = according to format in [RFC3966], e.g. 'tel:+1-201-555-0123'. = Service providers SHOULD canonicalize the value according to [RFC3966] = format, when appropriate. The = 'display' sub-attribute MAY be used to return the canonicalized = representation of the phone number value. Canonical type values = of "work", "home", "mobile", "fax", "pager", and = "other".

emails
E-mail addresses for the user. The value SHOULD be specified according = to [RFC5321]. Service providers SHOULD canonicalize the value = according to [RFC5321], e.g. "B.Jensen@example.com" instead of = "B.Jensen@EXAMPLE.COM". The 'display' sub-attribute MAY be used = to return the canonicalized representation of the phone number = value. Canonical type values of "work", "home", and = "other".


Regarding the = canonicalization of RFC 3966 phone numbers into separate "display" and = "type" values; e.g.

"type":"internal",
"display":"7042",
"value":"tel:7042;phone-context=3Dinterna= l"

I= 'd suggest omitting this type of behavior. Canonicalization to RFC 3966 = alone should be sufficient, and consumers reading data are welcome to = further parse the RFC phone number. Overloading the use of "type" with = non-canonical values may add unnecessary complexity to parsing for both = SPs and consumers.

For example, I'd merely suggest the = following type of canonicalizations:

Request:
"value":"tel:7042;phone-context=3Dinterna= l"
"type":"work"

Res= ponse:
"value":"tel:7042;phone-context=3Dinterna= l"
"display":"tel:7042;phone-context=3Dinterna= l"
"type":"work"

Req= uest:
"value":"+1 (201) = 555-0123"
"type":"work"
=
Response:
"value":"+1 (201) = 555-0123"
"display":"tel:+1-201-555-0123"
"type":"work"
=
 

On Wed, Oct 22, 2014 at 2:46 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Comments inline=85


On Oct 22, 2014, at 12:13 PM, Shelley = <randomshelley@gmail.com> = wrote:

Before any = specific text is proposed, I'd like to get a general understanding for = what the agreement/direction is. It seems there are still some major = open questions that I'd appreciate some input on.
  • Should = consumers be required to provide values in specific = formats?
    • For example, for phone numbers, must consumers = provide RFC 3966 format, an international format, any of multiple = common/pre-defined formats, or is any value allowed? If not in = RFC/international format, is the country/area code = assumed?
  • Should service providers perform attribute = validation or accept any values?
    • If service providers = perform validation, what is the expected behavior when validation fails? = (400 / ignore the value / store the value = as-is?)
  • Particularly if there are no requirements for data = input and/or no validation is performed:
    • What are the = assumptions that service providers can make during = canonicalization?
    • What should service providers / consumers do = if canonicalization is not possible?
    • Should the use of both the = "value" and "display" attributes be recommended?

There = are minimally two major variations of possible changes on the table, = with various flavors in between:

  • Require consumers to provide = values in specified formats and SPs perform validation, rejecting = invalid values
    • SCIM serves as a repository of well-formed, = valid data. This results in the most usable data for SCIM consumers = reading data, but puts some burden on SCIM consumers providing = the data to conform.
-OR-
  • Allow consumers = to provide values in any format, SP performs no validation though it may = attempt perform canonicalization
    • SCIM serves as a = repository of data from third parties, data may not be consistent, = valid, or normalized. This results in the least effort for SCIM = consumers providing data, but puts some burden on SCIM consumers = reading the data to make sense of the data.
    • SCIM SPs may = attempt to normalize some of the data, but there may be no = guarantees with respect to the consistency or accuracy of these = normalizations.
[PH - = <individualHat/>] I prefer this because it aligns with Postel=92s = Law.

I recommend stipulating that any = modification to the supplied values (e.g. canonicalization) by the = service providers MUST be reflected in the HTTP Response JSON = representation (e.g. after a POST = request). 

I think we also need to be = clear about how 3966 ABNF elements should map to SCIM's multi-valued = attribute representation for phoneNumbers. The earlier suggestion you = made is on the right track (mapping to display, type, value, etc).  = This might get a bit complex if for example the telephone number = includes embedded parameters *and* the client already specifies type, = value, and display representations.  My feeling is that the SP = should always honour any assigned =93type=94 value by the client.  = However, if the client does not assign a =93type=94, the SP could assign = one based on parsing parameters. For example, say a client provides a = value of "tel:7042;phone-context=3Dintern= al=94.  The server might = canonicalize/map as:

=93type=94:=94internal=94,
=93display=94:=947042=94,=
=93value=94:"tel:7042;phone-context=3Dinterna= l=94

More generically, here is one = possible mapping based on the ABNF from RFC3966 to phoneNumbers = attribute:

=93value=94: =93{telepho= ne-uri}=94
=93display=94:=94{global-number-= digits / local-number-digits}=94
=93type=94:=94{descriptor}=94

SP=92s may attempt to = canonicalize =93value=94 and normalize it. SPs may assign values = to =93display=94 and =93type=94 if the client has not asserted = values for these sub-attribues.

Regarding mapping of context = and descriptor to SCIM type, we would be profiling 3966 to say that the = ABNF  =93context=94 component is used and interpreted as a type. = (can anybody confirm I have interpreted use of context in 3966 = correctly?)


On= Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Shelley,

I think we = are pretty much in agreement. Would you mind providing some new text for = the definition of phoneNumbers?  I like where you are going with = value vs. displayName etc.

It would be good to = see how the group feels on a some new proposed = text.

Thanks,


On Oct 22, 2014, at 10:22 AM, Shelley <randomshelley@gmail.com> = wrote:

Thanks = for the response, Phil.

 If the SP can understand the value, it may = accept it.

Right, but what values can/should = SPs attempt to "understand" since these aren't described in the spec? = What assumptions, if any, can be made about the format provided by = consumers? Further, what happens if the SP doesn't "accept" the value: = 400 response? value is silently ignored? value is stored, but not = canonicalized?

Further it may modify the value to conform to = RFC3966 and return the modified value in the HTTP = response.

The problem here is that = modifying the value is not always possible or may be done incorrectly = depending on the format provided by the consumer.

Many service = providers would rather accept the POST and simply ignore the value than = to loose the transaction.

Silently = ignoring unknown values seems a bit dangerous as well. I agree that the = corrective action may be difficult to determine automatically if the = transaction fails fast, but at least it brings some form of visibility = to the problem.
 

On Wed, Oct 22, = 2014 at 11:39 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Shelley,

Than= ks for your comments and bringing this to the groups = attention.

Overall, I would like to strike a balance = in favour of being flexible in what is accepted.  If the SP can = understand the value, it may accept it. Further it may modify the value = to conform to RFC3966 and return the modified value in the HTTP = response. For example a service provider should feel free to = correct something in telephone-subscriber format to be returned as a URI = instead.
=97> maybe Postel=92s Law is one of the general = principles of SCIM that we should make more = clearer?

I think one of the problems with 3966 is = that it seems quite broadly defined. Enforcement may be quite valid. But = will it improve quality of information given the complication it will = cause for clients (e.g. when a request fails due to format, what is the = corrective action)?  Many service providers would rather accept the = POST and simply ignore the value than to loose the = transaction.

I agree we should adjust the = language a bit. For example, are we expecting a telephone-uri or a = telephone-subscriber as the value?  The spec is not clear. =  

There are also some other parts to 3966 = which duplicate what we are doing in multi-valued attributes. For = example the ABNF =93parameter=94 enables the following = example: 
  tel:704= 2;phone-context=3Dexample.com
In this case, = =93phone-context=94 could be seen as duplicative of the function of = =93type=94.

Maybe it is not only that we want = to following RFC3966, but we actually want to fully specify how 3966 is = mapped to phoneNumber=92s multi-valued JSON = structure?

Phil

@in= dependentid
phil.hunt@oracle.com

=


On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com> = wrote:

I'd also like to clarify/highlight this = problem/challenge with the current SCIM specification - the spec = recommends that service providers canonicalize phone numbers to RFC = 3966, yet, if there are no requirements for the data provided by the = consumer, this may be impossible.

In the extreme scenario, how = can a SCIM SP canonicalize "not a phone number" to RFC 3966? In an = incomplete scenario, how can an SP canonicalize "222-2222" without a = country/area code? And in an ambiguous scenario, how can an SP = canonicalize "201-5399 123" (where 123 is assumed to be an = extension)?

While it may be possible for the SP to = canonicalize some values under some assumptions (e.g. = country code may be assumed, and assumptions based on patterns, etc), it = is still possible that the canonicalization would be incorrect and in = some cases, impossible.

How are other SPs handling this? Is = anyone doing validation or canonicalization?

Likewise, how = are SCIM clients consuming phone numbers (especially those that may be = read-only consumers of data and don't have visibility/control over the = source data)? Is anyone doing any normalizing, validating, = canonicalizing, or just leaving the data as-is regardless of the = format/validity?


On Wed, Oct 22, = 2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> = wrote:
=20 =20 =20
Thanks - interesting link.
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888
On 22/10/2014 15:50, Shelley wrote:
The simplest approach would be to require SCIM consumers to provide phone numbers in the RFC 3966 format, which at least helps to guarantee the validity of the format and canonicalizes it into a standard global format consumable by both external systems and users. This also accounts for some of the scenarios you mentioned, such as sip calls.

As far as validating whether the phone number is actually a potentially valid number (based on country, area code, etc.), this can be discussed further/separately as well. I agree that validating whether a phone number is actually in service is probably not feasible but there are some standards and libraries that could potentially be used to deter completely bogus numbers [1], but the value in this may be debatable.

The overall problem is just that without centralized data validation in the service, SCIM consumers cannot rely on the syntax/validity of the data and therefore the burden of validating and normalizing falls to them.

[1] https://code.google.com/p/libphonenumber/


On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <aredston@switchresearch.com> wrote:
Of course the challenge here comes down to the extent to which that particular data can be standardised and validated. Taking phone numbers as the example you have sip calls, invalid numbers, country specific shortcodes, this is potentially a minefield.

Well formed and valid values are two distinct concepts and with multiple carrier technologies the anatomy of simple +4412345678901 style numbers is no longer fit for purpose. For this reason I do not think that it is feasible for this particular data type to be rejected as bad data because the only way to know if a phone number is valid is to dial = it.

What do you think?

Alex
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888
On 21/10/2014 20:36, Shelley wrote:
The SCIM specification expects service providers should be able to canonicalize provided data into a common format (e.g. RFC 3966 for phoneNumbers), yet it does not explicitly describe input requirements or validation for attributes such as these. Is it expected that values that cannot accurately be canonicalized are rejected by the SCIM service or that the SCIM service accepts this invalid data and merely persists and returns this bad data to consumers?

As a SCIM Service Provider, we are currently performing validation on attributes such as phoneNumbers and emails to ensure that they contain well-formed, valid values, and returning a 400 with a description of the error if validation fails. One of the benefits of SCIM is that data may come from multiple sources and may be consumed by multiple clients, and SCIM provides a repository of structured and well-formed data so that consumers can reliably derive meaning and use from this data. Without attribute validation and a guarantee of canonicalized values, this goal does not seem feasible and puts the burden on consumers to make sense of potentially invalid data.

The downside to attribute validation is that it requires the SCIM consumers sending data to ensure valid data as well. As these consumers are closest to the source data, though, this seems like the most reasonable approach rather than putting the burden on the service provider and/or other SCIM consumers to make sense of the data. Aside from just "bad data" (e.g. sending "not a phone number" or "000-0000" for a phone number), for example, if the SCIM consumer sending source data sends phone numbers without area codes or sends only internal extensions, another SCIM consumer may not be able to make sense of this data. It seems reasonable to require the consumer sending the data to ensure that this data is well-formed and canonicalized/canonicalizable.

A good example in the SCIM specification is the country attribute, which clearly indicates the attribute's requirements. A bad = example is the phoneNumbers attribute, which doesn't describe the expected format to be provided by consumers, yet recommends that the service provider canonicalize the value even though the input may not be able to be canonicalized.

I'd be interested in hearing others' opinions on this matter, and whether the SCIM specification should clarify further restrictions on attribute values.



=

This email is free from viruses and malware because avast! Antivirus protection is active.




=20

This email is free from viruses and = malware because avast!= Antivirus protection is active.



_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim




_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_C2B6B369-17B5-479A-90F0-88B82802E717-- From nobody Mon Nov 3 12:30:27 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114BE1A00F6 for ; Mon, 3 Nov 2014 12:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1jKAfg6abyU for ; Mon, 3 Nov 2014 12:30:24 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91661A00CD for ; Mon, 3 Nov 2014 12:30:23 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sA3KUKJo017408 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Nov 2014 21:30:21 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sA3KUIme020315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Nov 2014 21:30:20 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for scim@ietf.org; Mon, 3 Nov 2014 21:30:16 +0100 Message-ID: <5457E5D8.4010605@sunet.se> Date: Mon, 03 Nov 2014 21:30:16 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Nb8ulGw - e54cc447ca48 - 20141103 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9IMavRvAWbRJcD4sCMthVCl4Gtk Subject: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 20:30:26 -0000 Right now we don't have any extension proposals to talk about in Honolulu. What (if anything) should we cover in the room next week? Cheers Leif From nobody Mon Nov 3 15:18:48 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C41A8872 for ; Mon, 3 Nov 2014 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZoMe8IVDeUQ for ; Mon, 3 Nov 2014 15:18:44 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F921A8863 for ; Mon, 3 Nov 2014 15:18:44 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sA3NIfmj023884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Nov 2014 23:18:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA3NIeY1002808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Nov 2014 23:18:40 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA3NIdwm008232; Mon, 3 Nov 2014 23:18:39 GMT Received: from [192.168.1.10] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2014 15:18:39 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <5457E5D8.4010605@sunet.se> Date: Mon, 3 Nov 2014 15:18:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> References: <5457E5D8.4010605@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/dbctAHllfJ25oh2jF7pmf2_ePa0 Cc: "scim@ietf.org" Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 23:18:45 -0000 Leif, While there are probably a dozen items I could list, here are my top 3 = items... 1. SCIM Notifications 2. Password and other credential artifacts (e.g. strong auth, keys, = etc) 3. Possible session management and integration with OAuth - discussion Regarding item 1, I=92m happy to present some use case material on = behalf of Morteza, Ian, and myself. Item 2 - Bjorn - do you want to get together earlier next week and maybe = develop a common presentation? Item 3 - I=92m not sure this belongs in SCIM WG, but it seems to be = emerging now that SCIM is being seen as a =93cloud directory=94. This = might include integration and support of OAuth client credentials and = potentially integration with SCIM as an identity profile provider. I=92m happy to lead #3 (as well as #1), but if someone else has thoughts = already and would like to present, please advise. I=92m really just in = the early phases of thinking in this area. However it has begun to = emerge as an issue and seems like it is an emerging priority. We also had several =93schema extension=94 items as a working group that = we pushed out to allow completion of the core schema draft. I=92m = interested in hearing if anyone has any priorities or urgent = requirements here. Oracle has already developed many extensions of its = own, but I=92m not sure these are priority for inter-op (e.g. a new = Organization resourceType). They are all more =93nice-to-haves=94. So I = would support this work, just think they are lower on the priority list. Phil @independentid www.independentid.com phil.hunt@oracle.com On Nov 3, 2014, at 12:30 PM, Leif Johansson wrote: >=20 > Right now we don't have any extension proposals to talk about in > Honolulu. What (if anything) should we cover in the room next week? >=20 > Cheers Leif >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Nov 3 22:27:30 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430321A88C3 for ; Mon, 3 Nov 2014 22:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebg1np-k1hsp for ; Mon, 3 Nov 2014 22:27:26 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D971A88C2 for ; Mon, 3 Nov 2014 22:27:26 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id ge10so301778lab.22 for ; Mon, 03 Nov 2014 22:27:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WtFc+Ag+ZdJkilrnnjVJ/8tLVd2dZKG2QBqvtrTvq30=; b=Ggvth232exfKBM2tIfDH0ftizhEcY03aI4CDIVF+bEHsXBDt2q0K0mRK+uaOoRhX+y Tpe47iX8So1xZjLTxKPJCDScp8tR8lm/QbswNmF9a086/7s4vN3wXwF0STGMSUuEPPmZ dnZXU93EZOifqMv3siN3cz5lz+4qopk2yC3yfplmfG4gi+FQBQLRZR/KwJVoBgm776CT laE95EfgP9mKBydeXhCykGbiu1e+tkBGL+KzALp/TM9Zw0i+li6yVDLCMe/kuS8hqpus JNlhHLaos25S5wsY3UrA0QJjLBLHj00/teSxGmNq533Hu2owLUz3Uo/IQkPWSxHi6Jla PO8Q== X-Gm-Message-State: ALoCoQnqPFIrPIkde6G+KPsTt6n15q6b0AmNbnZqiD5/8tfrGoLtR3BN89064ita7LlKHT107HPv X-Received: by 10.112.167.130 with SMTP id zo2mr56608152lbb.4.1415082444324; Mon, 03 Nov 2014 22:27:24 -0800 (PST) Received: from [10.0.0.141] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ql6sm8798799lbb.31.2014.11.03.22.27.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 22:27:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12B411) In-Reply-To: <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> Date: Tue, 4 Nov 2014 07:27:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5457E5D8.4010605@sunet.se> <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/scim/YoZ8ua1IPYgyJ3nGqplb_QTFQyM Cc: "scim@ietf.org" , Leif Johansson Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 06:27:28 -0000 sounds like a plan! > 4 nov 2014 kl. 00:18 skrev Phil Hunt : >=20 > Leif, >=20 > While there are probably a dozen items I could list, here are my top 3 ite= ms... >=20 > 1. SCIM Notifications > 2. Password and other credential artifacts (e.g. strong auth, keys, etc) > 3. Possible session management and integration with OAuth - discussion >=20 > Regarding item 1, I=E2=80=99m happy to present some use case material on b= ehalf of Morteza, Ian, and myself. >=20 > Item 2 - Bjorn - do you want to get together earlier next week and maybe d= evelop a common presentation? >=20 > Item 3 - I=E2=80=99m not sure this belongs in SCIM WG, but it seems to be e= merging now that SCIM is being seen as a =E2=80=9Ccloud directory=E2=80=9D. = This might include integration and support of OAuth client credentials and p= otentially integration with SCIM as an identity profile provider. >=20 > I=E2=80=99m happy to lead #3 (as well as #1), but if someone else has thou= ghts already and would like to present, please advise. I=E2=80=99m really j= ust in the early phases of thinking in this area. However it has begun to em= erge as an issue and seems like it is an emerging priority. >=20 > We also had several =E2=80=9Cschema extension=E2=80=9D items as a working g= roup that we pushed out to allow completion of the core schema draft. I=E2=80= =99m interested in hearing if anyone has any priorities or urgent requiremen= ts here. Oracle has already developed many extensions of its own, but I=E2=80= =99m not sure these are priority for inter-op (e.g. a new Organization resou= rceType). They are all more =E2=80=9Cnice-to-haves=E2=80=9D. So I would sup= port this work, just think they are lower on the priority list. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Nov 3, 2014, at 12:30 PM, Leif Johansson wrote: >>=20 >>=20 >> Right now we don't have any extension proposals to talk about in >> Honolulu. What (if anything) should we cover in the room next week? >>=20 >> Cheers Leif >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Nov 3 22:43:18 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F071A88CE for ; Mon, 3 Nov 2014 22:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OYceEXtiA7n for ; Mon, 3 Nov 2014 22:43:15 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86731A04BA for ; Mon, 3 Nov 2014 22:43:14 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sA46hCe3005177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Nov 2014 06:43:13 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA46hBTK027783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Nov 2014 06:43:12 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA46hBlR001689; Tue, 4 Nov 2014 06:43:11 GMT Received: from [192.168.1.10] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2014 22:43:11 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 3 Nov 2014 22:43:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF2EAFD-0D06-43B9-AFA4-BAB89C47EA82@oracle.com> References: <5457E5D8.4010605@sunet.se> <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> To: Leif Johansson X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zzhwVu4ZM8dee0K5iMmPoNiX6ew Cc: "scim@ietf.org" , Leif Johansson , Anthony Nadalin Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 06:43:16 -0000 Leif, Just remembered a couple more: * Async & Workflow processing. * Tony mentioned Mark Wahl's provision on-demand (or JIT) draft that was = submitted some time ago at IIW last week. Would be great if someone = from MS can talk about that some more. See: = http://tools.ietf.org/html/draft-wahl-scim-jit-profile-02 Phil @independentid www.independentid.com phil.hunt@oracle.com On Nov 3, 2014, at 10:27 PM, Leif Johansson wrote: > sounds like a plan! >=20 >=20 >> 4 nov 2014 kl. 00:18 skrev Phil Hunt : >>=20 >> Leif, >>=20 >> While there are probably a dozen items I could list, here are my top = 3 items... >>=20 >> 1. SCIM Notifications >> 2. Password and other credential artifacts (e.g. strong auth, keys, = etc) >> 3. Possible session management and integration with OAuth - = discussion >>=20 >> Regarding item 1, I=92m happy to present some use case material on = behalf of Morteza, Ian, and myself. >>=20 >> Item 2 - Bjorn - do you want to get together earlier next week and = maybe develop a common presentation? >>=20 >> Item 3 - I=92m not sure this belongs in SCIM WG, but it seems to be = emerging now that SCIM is being seen as a =93cloud directory=94. This = might include integration and support of OAuth client credentials and = potentially integration with SCIM as an identity profile provider. >>=20 >> I=92m happy to lead #3 (as well as #1), but if someone else has = thoughts already and would like to present, please advise. I=92m really = just in the early phases of thinking in this area. However it has begun = to emerge as an issue and seems like it is an emerging priority. >>=20 >> We also had several =93schema extension=94 items as a working group = that we pushed out to allow completion of the core schema draft. I=92m = interested in hearing if anyone has any priorities or urgent = requirements here. Oracle has already developed many extensions of its = own, but I=92m not sure these are priority for inter-op (e.g. a new = Organization resourceType). They are all more =93nice-to-haves=94. So I = would support this work, just think they are lower on the priority list. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On Nov 3, 2014, at 12:30 PM, Leif Johansson wrote: >>>=20 >>>=20 >>> Right now we don't have any extension proposals to talk about in >>> Honolulu. What (if anything) should we cover in the room next week? >>>=20 >>> Cheers Leif >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Tue Nov 4 00:47:42 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC041A8910 for ; Tue, 4 Nov 2014 00:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJJ3mFCpKRvk for ; Tue, 4 Nov 2014 00:47:28 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF9D1A8882 for ; Tue, 4 Nov 2014 00:47:27 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so540103lbg.0 for ; Tue, 04 Nov 2014 00:47:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HgisOYAqD6P6/1FnRp6YOiXVWX0JOar+SFVDI6lZl60=; b=GlCEa1u6cFpiZkJBncsKViLZ2qAV4xQzy+u/13HFDm2ILkOzEphVIQo58IuXi2LW7a aqQXdHm8/7GpERhHyzdyCVOAKC8/kraMIr/mHqW1e7mVXrrBP0FKNzSwIortsM0ZaCcN rEy9H9gtCt/xGG/tdtuJXpf5rL8BSA/yXuTEBJEZOQ9UBh4fo80aLzLThjAdJHst7HjQ FiRlzWGXC6+WQLW1F8MU0IDbgq190EXwJIjicgthMK2F7O1ZgIJ1ABxCQYkb0bioLsE6 Wgk302DJTGjp27YGCwx8kxMElayRg25qHxVJw20AYlR7s7R1Cfd2z+PnMfcbkWv42oqA HLSw== X-Gm-Message-State: ALoCoQn/5YwnLka3fVdmS0Q3NmJm658F5VTeTOgHgx49UqWXcf/IIvG3D58e0vg8RgxW7OsCWtV5 X-Received: by 10.112.171.225 with SMTP id ax1mr53208881lbc.40.1415090846135; Tue, 04 Nov 2014 00:47:26 -0800 (PST) Received: from [193.10.94.8] ([193.10.94.8]) by mx.google.com with ESMTPSA id nb7sm8904629lbb.43.2014.11.04.00.47.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 00:47:25 -0800 (PST) Message-ID: <5458929D.5030503@mnt.se> Date: Tue, 04 Nov 2014 09:47:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Phil Hunt References: <5457E5D8.4010605@sunet.se> <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> <2BF2EAFD-0D06-43B9-AFA4-BAB89C47EA82@oracle.com> In-Reply-To: <2BF2EAFD-0D06-43B9-AFA4-BAB89C47EA82@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lenoYAzPCKUJld1QeiRZt3mbOR0 Cc: "scim@ietf.org" , Leif Johansson , Anthony Nadalin Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 08:47:34 -0000 Here is the current agenda draft that I'll post in a minute. I've listed stuff where somebody has clearly said "I'll present X" - all other topics are under "open mic" for now. If anybody else wants to present (Björn?) we can always slice the 90 minutes up a bit differently between next steps and open mic. Cheers Leif Agenda for SCIM IETF91 - Note Well & Agenda Bashing (5min) - Core document status (5min) - Next steps and future work (40min) + soft deletes (Morteza) + scim notifications (Phil) + scim and oauth (Phil) - Recharter & Open Mic (30min) From nobody Tue Nov 4 09:49:12 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4337E1ACCE6 for ; Tue, 4 Nov 2014 09:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdH_WyztFknc for ; Tue, 4 Nov 2014 09:48:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17041ACCE3 for ; Tue, 4 Nov 2014 09:48:56 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 4 Nov 2014 17:48:34 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0011.000; Tue, 4 Nov 2014 17:48:34 +0000 From: Anthony Nadalin To: Leif Johansson , Phil Hunt Thread-Topic: [scim] agenda for Honolulu Thread-Index: AQHP96UE0qWSCsu1nUasF4lVVAX2V5xPibOAgAB3zICAAL4bQA== Date: Tue, 4 Nov 2014 17:48:33 +0000 Message-ID: References: <5457E5D8.4010605@sunet.se> <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-prvs: 03853D523D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(53824002)(13464003)(199003)(377454003)(51164003)(51704005)(24454002)(99286002)(19580395003)(108616004)(95666004)(106356001)(105586002)(122556002)(19580405001)(64706001)(120916001)(46102003)(99396003)(15974865002)(77096003)(20776003)(21056001)(77156002)(40100003)(107046002)(62966003)(106116001)(101416001)(97736003)(76576001)(76176999)(54356999)(33646002)(86612001)(86362001)(92566001)(31966008)(15975445006)(74316001)(551544002)(50986999)(87936001)(2656002)(4396001)(24736002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/wvQMQ1cQ-Y77fKo5YgyApAHlzVY Cc: "scim@ietf.org" , Leif Johansson Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 17:49:01 -0000 SSdtIGp1c3Qgd29uZGVyaW5nIHRoZSBpZGVhIGJlaGluZCBkaXNjdXNzaW5nIG5vdGlmaWNhdGlv bnMgYXMgdGhpcyBzZWVtcyBsaWtlIGEgbmV2ZXIgZW5kaW5nIGRpc2N1c3Npb24gPw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlaWYgSm9oYW5zc29uDQpTZW50OiBNb25kYXksIE5vdmVt YmVyIDMsIDIwMTQgMTA6MjcgUE0NClRvOiBQaGlsIEh1bnQNCkNjOiBzY2ltQGlldGYub3JnOyBM ZWlmIEpvaGFuc3Nvbg0KU3ViamVjdDogUmU6IFtzY2ltXSBhZ2VuZGEgZm9yIEhvbm9sdWx1DQoN CnNvdW5kcyBsaWtlIGEgcGxhbiENCg0KDQo+IDQgbm92IDIwMTQga2wuIDAwOjE4IHNrcmV2IFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+Og0KPiANCj4gTGVpZiwNCj4gDQo+IFdoaWxl IHRoZXJlIGFyZSBwcm9iYWJseSBhIGRvemVuIGl0ZW1zIEkgY291bGQgbGlzdCwgaGVyZSBhcmUg bXkgdG9wIDMgaXRlbXMuLi4NCj4gDQo+IDEuICBTQ0lNIE5vdGlmaWNhdGlvbnMNCj4gMi4gIFBh c3N3b3JkIGFuZCBvdGhlciBjcmVkZW50aWFsIGFydGlmYWN0cyAoZS5nLiBzdHJvbmcgYXV0aCwg a2V5cywgDQo+IGV0YykgMy4gIFBvc3NpYmxlIHNlc3Npb24gbWFuYWdlbWVudCBhbmQgaW50ZWdy YXRpb24gd2l0aCBPQXV0aCAtIA0KPiBkaXNjdXNzaW9uDQo+IA0KPiBSZWdhcmRpbmcgaXRlbSAx LCBJ4oCZbSBoYXBweSB0byBwcmVzZW50IHNvbWUgdXNlIGNhc2UgbWF0ZXJpYWwgb24gYmVoYWxm IG9mIE1vcnRlemEsIElhbiwgYW5kIG15c2VsZi4NCj4gDQo+IEl0ZW0gMiAtIEJqb3JuIC0gZG8g eW91IHdhbnQgdG8gZ2V0IHRvZ2V0aGVyIGVhcmxpZXIgbmV4dCB3ZWVrIGFuZCBtYXliZSBkZXZl bG9wIGEgY29tbW9uIHByZXNlbnRhdGlvbj8NCj4gDQo+IEl0ZW0gMyAtIEnigJltIG5vdCBzdXJl IHRoaXMgYmVsb25ncyBpbiBTQ0lNIFdHLCBidXQgaXQgc2VlbXMgdG8gYmUgZW1lcmdpbmcgbm93 IHRoYXQgU0NJTSBpcyBiZWluZyBzZWVuIGFzIGEg4oCcY2xvdWQgZGlyZWN0b3J54oCdLiAgVGhp cyBtaWdodCBpbmNsdWRlIGludGVncmF0aW9uIGFuZCBzdXBwb3J0IG9mIE9BdXRoIGNsaWVudCBj cmVkZW50aWFscyBhbmQgcG90ZW50aWFsbHkgaW50ZWdyYXRpb24gd2l0aCBTQ0lNIGFzIGFuIGlk ZW50aXR5IHByb2ZpbGUgcHJvdmlkZXIuDQo+IA0KPiBJ4oCZbSBoYXBweSB0byBsZWFkICMzIChh cyB3ZWxsIGFzICMxKSwgYnV0IGlmIHNvbWVvbmUgZWxzZSBoYXMgdGhvdWdodHMgYWxyZWFkeSBh bmQgd291bGQgbGlrZSB0byBwcmVzZW50LCBwbGVhc2UgYWR2aXNlLiAgSeKAmW0gcmVhbGx5IGp1 c3QgaW4gdGhlIGVhcmx5IHBoYXNlcyBvZiB0aGlua2luZyBpbiB0aGlzIGFyZWEuIEhvd2V2ZXIg aXQgaGFzIGJlZ3VuIHRvIGVtZXJnZSBhcyBhbiBpc3N1ZSBhbmQgc2VlbXMgbGlrZSBpdCBpcyBh biBlbWVyZ2luZyBwcmlvcml0eS4NCj4gDQo+IFdlIGFsc28gaGFkIHNldmVyYWwg4oCcc2NoZW1h IGV4dGVuc2lvbuKAnSBpdGVtcyBhcyBhIHdvcmtpbmcgZ3JvdXAgdGhhdCB3ZSBwdXNoZWQgb3V0 IHRvIGFsbG93IGNvbXBsZXRpb24gb2YgdGhlIGNvcmUgc2NoZW1hIGRyYWZ0LiBJ4oCZbSBpbnRl cmVzdGVkIGluIGhlYXJpbmcgaWYgYW55b25lIGhhcyBhbnkgcHJpb3JpdGllcyBvciB1cmdlbnQg cmVxdWlyZW1lbnRzIGhlcmUuICBPcmFjbGUgaGFzIGFscmVhZHkgZGV2ZWxvcGVkIG1hbnkgZXh0 ZW5zaW9ucyBvZiBpdHMgb3duLCBidXQgSeKAmW0gbm90IHN1cmUgdGhlc2UgYXJlIHByaW9yaXR5 IGZvciBpbnRlci1vcCAoZS5nLiBhIG5ldyBPcmdhbml6YXRpb24gcmVzb3VyY2VUeXBlKS4gVGhl eSBhcmUgYWxsIG1vcmUg4oCcbmljZS10by1oYXZlc+KAnS4gIFNvIEkgd291bGQgc3VwcG9ydCB0 aGlzIHdvcmssIGp1c3QgdGhpbmsgdGhleSBhcmUgbG93ZXIgb24gdGhlIHByaW9yaXR5IGxpc3Qu DQo+IA0KPiBQaGlsDQo+IA0KPiBAaW5kZXBlbmRlbnRpZA0KPiB3d3cuaW5kZXBlbmRlbnRpZC5j b20NCj4gcGhpbC5odW50QG9yYWNsZS5jb20NCj4gDQo+IA0KPiANCj4+IE9uIE5vdiAzLCAyMDE0 LCBhdCAxMjozMCBQTSwgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPiB3cm90ZToNCj4+ IA0KPj4gDQo+PiBSaWdodCBub3cgd2UgZG9uJ3QgaGF2ZSBhbnkgZXh0ZW5zaW9uIHByb3Bvc2Fs cyB0byB0YWxrIGFib3V0IGluIA0KPj4gSG9ub2x1bHUuIFdoYXQgKGlmIGFueXRoaW5nKSBzaG91 bGQgd2UgY292ZXIgaW4gdGhlIHJvb20gbmV4dCB3ZWVrPw0KPj4gDQo+PiAgICBDaGVlcnMgTGVp Zg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc2NpbSBtYWlsaW5nIGxpc3QNCj4+IHNjaW1AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2NpbSBtYWlsaW5nIGxpc3QNCj4gc2Np bUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0g bWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NjaW0NCg== From nobody Tue Nov 4 12:37:03 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28FB1ACEDC for ; Tue, 4 Nov 2014 12:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A1G3TYyHFp9 for ; Tue, 4 Nov 2014 12:36:58 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FC41A7D82 for ; Tue, 4 Nov 2014 12:36:58 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sA4Kauso003714 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Nov 2014 21:36:56 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sA4KaqLZ026904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2014 21:36:55 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 4 Nov 2014 21:36:50 +0100 Message-ID: <545938E2.7050807@sunet.se> Date: Tue, 04 Nov 2014 21:36:50 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Anthony Nadalin , Leif Johansson , Phil Hunt References: <5457E5D8.4010605@sunet.se> <369E32CE-C44C-4F37-8CD7-5BCC23C0B1D7@oracle.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NbwAUMI - 5f3dd9995136 - 20141104 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Plq3i5OK3D0aL447G5kOSW_Blqw Cc: "scim@ietf.org" Subject: Re: [scim] agenda for Honolulu X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 20:37:00 -0000 On 2014-11-04 18:48, Anthony Nadalin wrote: > I'm just wondering the idea behind discussing notifications as this seems like a never ending discussion ? > It will be time-boxed in our agenda so I'm not worried. From prvs=38413a528=rjongeneelen@sdl.com Mon Nov 10 10:43:58 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5F1A86FF for ; Mon, 10 Nov 2014 10:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey7V0CsnF2Ln for ; Mon, 10 Nov 2014 10:43:55 -0800 (PST) Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10F01A8943 for ; Mon, 10 Nov 2014 10:43:54 -0800 (PST) Received: from mailus.sdl.com (mailus.sdl.com [65.100.157.33]) by rly09a.srv.mailcontrol.com (MailControl) with ESMTP id sAAIhotg002495 for ; Mon, 10 Nov 2014 18:43:51 GMT X-Disclaimer: None X-Disclaimer-HTML: HTML Received: from BL-EXCH01.global.sdl.corp ([fe80::5a4:f9c4:b6b1:4a01]) by bl-exch02.global.sdl.corp ([fe80::51c3:7bd3:873e:b33c%16]) with mapi id 14.03.0210.002; Mon, 10 Nov 2014 18:43:46 +0000 From: Remo Jongeneelen To: "scim@ietf.org" Thread-Topic: attribute externalId inconsistency Thread-Index: Ac/9FS2uiyGq8pl5Q0+1gW95CYKrsQ== Date: Mon, 10 Nov 2014 18:43:45 +0000 Message-ID: <517033CE58389E45B0072326A19ABB046D0A3E3B@bl-exch01.global.sdl.corp> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.110.222.199] Content-Type: multipart/alternative; boundary="_000_517033CE58389E45B0072326A19ABB046D0A3E3Bblexch01globals_" MIME-Version: 1.0 X-Scanned-By: MailControl 35930.357 (www.mailcontrol.com) on 10.65.0.119 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/TW5h3tNZrCKeYroN5HsmTJ6oow4 Subject: [scim] attribute externalId inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:45:17 -0000 --_000_517033CE58389E45B0072326A19ABB046D0A3E3Bblexch01globals_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In draft-scim-core-schema-12 there seems to be an inconsistency between the description of= the Common Attribute 'externalId' and the example making use of it. Section 3.1 describes it as: externalId A String that is an identifier for the resource as defined by the provisioning client. ... while the example in section 8.2 shows this attribute as an array of String= , not as a String: { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id": "2819c223-7f76-453a-919d-413861904646", "externalId": ["701984"], ... I presume the sample is invalid by showing an array, is that correct? Thanks in advance. Kind regards Remo Jongeneelen | Architect for Group Technology and Innovation | SDL | (t= ) +1 310 944 1904 <= br>
www.sdl.com

SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and require= s that you delete it without acting upon or copying any of its contents,=20 and we further request that you advise us.

SDL Enterprise Technologies, Inc. - all rights reserved. The information c= ontained in this email may be confidential and/or legally privileged. It ha= s been sent for the sole use of the intended recipient(s). If you are not t= he intended recipient of this mail, you are hereby notified that any unauth= orized review, use, disclosure, dissemination, distribution, or copying of = this communication, or any of its contents, is strictly prohibited. If you = have received this communication in error, please reply to the sender and d= estroy all copies of the message.
Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880= , USA This message has been scanned for malware by Websense. www.websense.com --_000_517033CE58389E45B0072326A19ABB046D0A3E3Bblexch01globals_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In draft-scim-core-schema-12 there seems to be an inconsistency between th= e description of the Common Attribute ‘externalId’ and the exam= ple making use of it.

 

Section 3.1 describes it as:

externalId

      A String that is an identifier for the resource as defined by the

      provisioning clien= t. …

 

while the example in section 8.2 shows this attribut= e as an array of String, not as a String:

 

{

  "schemas": ["urn:ietf:param= s:scim:schemas:core:2.0:User"],

  "id": "2819c223-7f76-453a-9= 19d-413861904646",

  "externalId": ["701984"],

   …

 

I presume the sample is invalid by showing an array,= is that correct?

 

Thanks in advance.

 

Kind regards

Remo Jongeneelen | Architect for Group Technology and Innova= tion | SDL | (t) +1 310 944 1904

 






<=
br>
www.sdl.com






SDL PLC confidential, all rights reserved.

If you are not the intended recipient of this mail SDL requests and require=
s that you delete it without acting upon or copying any of its contents,=20
and we further request that you advise us.


SDL Enterprise Technologies, Inc. - all rights reserved.  The information c=
ontained in this email may be confidential and/or legally privileged. It ha=
s been sent for the sole use of the intended recipient(s). If you are not t=
he intended recipient of this mail, you are hereby notified that any unauth=
orized review, use, disclosure, dissemination, distribution, or copying of =
this communication, or any of its contents, is strictly prohibited. If you =
have received this communication in error, please reply to the sender and d=
estroy all copies of the message.

Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880=
, USA





This message ha=
s been scanned for malware by Websense.  www.web=
sense.com




--_000_517033CE58389E45B0072326A19ABB046D0A3E3Bblexch01globals_--


From nobody Mon Nov 10 17:21:13 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2619A1A6EE8 for ; Mon, 10 Nov 2014 17:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.793
X-Spam-Level: 
X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7MhgHE0JrHS for ; Mon, 10 Nov 2014 17:21:07 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A091ACDE5 for ; Mon, 10 Nov 2014 17:21:07 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAB1L6VU020139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 01:21:07 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAB1L5ur029586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 01:21:06 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAB1L4jZ001950; Tue, 11 Nov 2014 01:21:04 GMT
Received: from dhcp-8e0d.meeting.ietf.org (/31.133.142.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Nov 2014 17:21:04 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_C7D2A68E-A45C-4F26-99AA-C1AB30C69366"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Phil Hunt 
In-Reply-To: <517033CE58389E45B0072326A19ABB046D0A3E3B@bl-exch01.global.sdl.corp>
Date: Mon, 10 Nov 2014 15:21:02 -1000
Message-Id: 
References: <517033CE58389E45B0072326A19ABB046D0A3E3B@bl-exch01.global.sdl.corp>
To: Remo Jongeneelen 
X-Mailer: Apple Mail (2.1990.1)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HUbrIre7Gza_jhRTX77DvJiOPag
Cc: "scim@ietf.org" 
Subject: Re: [scim] attribute externalId inconsistency
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Nov 2014 01:21:11 -0000

--Apple-Mail=_C7D2A68E-A45C-4F26-99AA-C1AB30C69366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Remo,

Sorry for the delay in replying.=20

It is supposed to be a single String value in the example.

I will add the example to the nit list for the next draft.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 10, 2014, at 8:43 AM, Remo Jongeneelen  =
wrote:
>=20
> Hi,
> =20
> In draft-scim-core-schema-12 =
 there seems =
to be an inconsistency between the description of the Common Attribute =
=E2=80=98externalId=E2=80=99 and the example making use of it.
> =20
> Section 3.1 describes it as:
> externalId
>       A String that is an identifier for the resource as defined by =
the
>       provisioning client. =E2=80=A6
> =20
> while the example in section 8.2 shows this attribute as an array of =
String, not as a String:
> =20
> {
>   "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "externalId": ["701984"],
>    =E2=80=A6
> =20
> I presume the sample is invalid by showing an array, is that correct?
> =20
> Thanks in advance.
> =20
> Kind regards
> Remo Jongeneelen | Architect for Group Technology and Innovation | SDL =
| (t) +1 310 944 1904
> =20
> =20
>=20
> www.sdl.com  =

>=20
> SDL PLC confidential, all rights reserved. If you are not the intended =
recipient of this mail SDL requests and requires that you delete it =
without acting upon or copying any of its contents, and we further =
request that you advise us.
>=20
> SDL Enterprise Technologies, Inc. - all rights reserved. The =
information contained in this email may be confidential and/or legally =
privileged. It has been sent for the sole use of the intended =
recipient(s). If you are not the intended recipient of this mail, you =
are hereby notified that any unauthorized review, use, disclosure, =
dissemination, distribution, or copying of this communication, or any of =
its contents, is strictly prohibited. If you have received this =
communication in error, please reply to the sender and destroy all =
copies of the message.=20
> Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA =
01880, USA=20
>=20
> This message has been scanned for malware by Websense. =
www.websense.com =
_______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_C7D2A68E-A45C-4F26-99AA-C1AB30C69366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Remo,

Sorry=
 for the delay in replying. 

It is supposed to be a single String =
value in the example.

I will add the example to the nit list for the next =
draft.






On Nov 10, 2014, at 8:43 AM, Remo Jongeneelen <rjongeneelen@sdl.com> wrote:










Hi,
 
In 
draft-scim-core-schema-12 there seems to be an inconsistency between =
the description of the Common Attribute =E2=80=98externalId=E2=80=99 and =
the example making use of it.
 
Section 3.1 describes it as:
externalId
      
A String that is an identifier for the resource as defined by =
the
      provisioning client. =E2=80=A6
 
while the example in =
section 8.2 shows this attribute as an array of String, not as a =
String:
 
{
  =
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  =
"id": "2819c223-7f76-453a-919d-413861904646",
  =
"externalId": ["701984"],
  =
 =E2=80=A6
 
I presume the sample =
is invalid by showing an array, is that correct?
 
Thanks in advance.
 
Kind regards
Remo Jongeneelen |
Architect for Group Technology and Innovation |
SDL
|
(t)
+1 310 944 1904
 








=



www.sdl.com






SDL PLC confidential, all rights reserved.

If you are not the intended recipient of this mail SDL requests and =
requires that you delete it without acting upon or copying any of its =
contents,=20
and we further request that you advise us.


SDL Enterprise Technologies, Inc. - all rights reserved.  The =
information contained in this email may be confidential and/or legally =
privileged. It has been sent for the sole use of the intended =
recipient(s). If you are not the intended recipient of this mail, you =
are hereby notified that any unauthorized review, use, disclosure, =
dissemination, distribution, or copying of this communication, or any of =
its contents, is strictly prohibited. If you have received this =
communication in error, please reply to the sender and destroy all =
copies of the message.

Registered address: 201 Edgewater Drive, Suite 225, =
Wakefield, MA 01880, USA



This message has been =
scanned for malware by Websense.  www.websense.com


=


_______________________________________________
scim =
mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

=

--Apple-Mail=_C7D2A68E-A45C-4F26-99AA-C1AB30C69366--


From nobody Tue Nov 11 12:15:25 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5088D1A90B1 for ; Tue, 11 Nov 2014 12:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuVIQ0xl87AH for ; Tue, 11 Nov 2014 12:15:04 -0800 (PST)
Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1581A1A9082 for ; Tue, 11 Nov 2014 12:14:10 -0800 (PST)
Received: from mailus.sdl.com (mailus.sdl.com [65.100.157.33]) by rly23a.srv.mailcontrol.com (MailControl) with ESMTP id sABKE6Hd035232 for ; Tue, 11 Nov 2014 20:14:06 GMT
X-Disclaimer: None
X-Disclaimer-HTML: HTML
Received: from BL-EXCH01.global.sdl.corp ([fe80::5a4:f9c4:b6b1:4a01]) by to-exch03.global.sdl.corp ([fe80::5fa:baf3:1152:680f%16]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 05:14:04 +0900
From: Remo Jongeneelen 
To: Phil Hunt 
Thread-Topic: [scim] attribute externalId inconsistency
Thread-Index: Ac/9FS2uiyGq8pl5Q0+1gW95CYKrsQAOJP0AACeSHT0=
Date: Tue, 11 Nov 2014 20:14:04 +0000
Message-ID: 
References: <517033CE58389E45B0072326A19ABB046D0A3E3B@bl-exch01.global.sdl.corp>,  
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_F17C929F029646628DB9111E7D43E5F4sdlcom_"
MIME-Version: 1.0
X-Scanned-By: MailControl 35930.357 (www.mailcontrol.com) on 10.65.0.133
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ov0Ak4lho2aCgECFgfYk6ft5d34
Cc: "scim@ietf.org" 
Subject: Re: [scim] attribute externalId inconsistency
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Nov 2014 20:15:14 -0000

--_000_F17C929F029646628DB9111E7D43E5F4sdlcom_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

Thanks Phil for the quick and clear answer. Currently we are actively inple=
menting a SCIM 2 service within SDL; I will try to collect some of the ques=
tions/unclarities we ran into and will send them to this mailing list soon.

If we have ideas for improvement, can I send them to this mailinglist also?

Kind regards

Remo

On Nov 10, 2014, at 5:21 PM, "Phil Hunt" > wrote:

Remo,

Sorry for the delay in replying.

It is supposed to be a single String value in the example.

I will add the example to the nit list for the next draft.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Nov 10, 2014, at 8:43 AM, Remo Jongeneelen > wrote:

Hi,

In draft-scim-core-schema-12 there seems to be an inconsistency between the description of=
 the Common Attribute =91externalId=92 and the example making use of it.

Section 3.1 describes it as:
externalId
      A String that is an identifier for the resource as defined by the
      provisioning client. =85

while the example in section 8.2 shows this attribute as an array of String=
, not as a String:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": ["701984"],
   =85

I presume the sample is invalid by showing an array, is that correct?

Thanks in advance.

Kind regards
Remo Jongeneelen | Architect for Group Technology and Innovation | SDL | (t=
) +1 310 944 1904


[http://www.sdl.com/Content/images/SDLlogo2014.png]

www.sdl.com 

SDL PLC confidential, all rights reserved. If you are not the intended reci=
pient of this mail SDL requests and requires that you delete it without act=
ing upon or copying any of its contents, and we further request that you ad=
vise us.

SDL Enterprise Technologies, Inc. - all rights reserved. The information co=
ntained in this email may be confidential and/or legally privileged. It has=
 been sent for the sole use of the intended recipient(s). If you are not th=
e intended recipient of this mail, you are hereby notified that any unautho=
rized review, use, disclosure, dissemination, distribution, or copying of t=
his communication, or any of its contents, is strictly prohibited. If you h=
ave received this communication in error, please reply to the sender and de=
stroy all copies of the message.
Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880, USA


This message has been scanned for malware by Websense. www.websense.com

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim




Click here to report this=
 email as spam.





<=
br>
www.sdl.com






SDL PLC confidential, all rights reserved.

If you are not the intended recipient of this mail SDL requests and require=
s that you delete it without acting upon or copying any of its contents,=20
and we further request that you advise us.


SDL Enterprise Technologies, Inc. - all rights reserved.  The information c=
ontained in this email may be confidential and/or legally privileged. It ha=
s been sent for the sole use of the intended recipient(s). If you are not t=
he intended recipient of this mail, you are hereby notified that any unauth=
orized review, use, disclosure, dissemination, distribution, or copying of =
this communication, or any of its contents, is strictly prohibited. If you =
have received this communication in error, please reply to the sender and d=
estroy all copies of the message.

Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880=
, USA


--_000_F17C929F029646628DB9111E7D43E5F4sdlcom_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="windows-1252"







Thanks Phil for the quick and clear answer. Currently we are actively =
inplementing a SCIM 2 service within SDL; I will try to collect some of the=
 questions/unclarities we ran into and will send them to this mailing list =
soon.







If we have ideas for improvement, can I send them to this mailinglist =
also?







Kind regards







Remo




On Nov 10, 2014, at 5:21 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:








Remo,






Sorry for the delay in replying. 







It is supposed to be a single String value in the example.<=
/div>






I will add the example to the nit list for the next draft.<=
/div>




























Phil







@independentid


www.ind=
ependentid.com



phil.hunt@oracle.=
com
























On Nov 10, 2014, at 8:43 AM, Remo Jongeneelen <rjongeneelen@sdl.com> wr=
ote:












Hi,


 


In 
draft-scim-core-schema-12 there seems to be an inconsistency between th=
e description of the Common Attribute =91externalId=92 and the example maki=
ng use of it.


 


Section 3.1 describes it as:

externalId

      
A String that is an identifier for the resource as defined by the


      provisi=
oning client. =85


 


while the example in section 8.2 shows this attribut=
e as an array of String, not as a String:


 


{


  "schemas": ["urn=
:ietf:params:scim:schemas:core:2.0:User"],

  "id": "2819c223-=
7f76-453a-919d-413861904646",


  
"externalId": ["701984"],<=
/i>


   =85=



 


I presume the sample is invalid by showing an array,=
 is that correct?


 


Thanks in advance.


 


Kind regards


Remo Jongeneelen&n=
bsp;|=

Architect for Group Technology=
 and Innovation =
;|
SDL
|
(t)
+1 310 944 1904


 





<=
br class=3D"">


www.sdl.com 



=
SDL PLC confidential, all rights reserved. If you are not the intended =
recipient of this mail SDL requests and requires that you delete it without=
 acting upon or copying any of its contents,
 and we further request that you advise us.



SDL Enterprise Technologies, Inc. - all rights reserved. The information co=
ntained in this email may be confidential and/or legally privileged. It has=
 been sent for the sole use of the intended recipient(s). If you are not th=
e intended recipient of this mail,
 you are hereby notified that any unauthorized review, use, disclosure, dis=
semination, distribution, or copying of this communication, or any of its c=
ontents, is strictly prohibited. If you have received this communication in=
 error, please reply to the sender
 and destroy all copies of the message. 

Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880, US=
A 





This message has been scanned for malware by Websense.
www.websense.com



______________=
_________________________________

scim mailing list

scim@ietf.org

https://www.ietf.org=
/mailman/listinfo/scim

















Click 
here to report this email as spam.











<=
br>
www.sdl.com






SDL PLC confidential, all rights reserved.

If you are not the intended recipient of this mail SDL requests and require=
s that you delete it without acting upon or copying any of its contents,=20
and we further request that you advise us.


SDL Enterprise Technologies, Inc. - all rights reserved.  The information c=
ontained in this email may be confidential and/or legally privileged. It ha=
s been sent for the sole use of the intended recipient(s). If you are not t=
he intended recipient of this mail, you are hereby notified that any unauth=
orized review, use, disclosure, dissemination, distribution, or copying of =
this communication, or any of its contents, is strictly prohibited. If you =
have received this communication in error, please reply to the sender and d=
estroy all copies of the message.

Registered address: 201 Edgewater Drive, Suite 225, Wakefield, MA 01880=
, USA




--_000_F17C929F029646628DB9111E7D43E5F4sdlcom_--


From nobody Fri Nov 14 15:26:12 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7966D1AD3C6 for ; Fri, 14 Nov 2014 15:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.465
X-Spam-Level: 
X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whNJQbe1Q56O for ; Fri, 14 Nov 2014 15:26:06 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41901AD3BF for ; Fri, 14 Nov 2014 15:26:03 -0800 (PST)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sAENQ1oI019806 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Nov 2014 00:26:02 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sAENPw0g013847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Nov 2014 00:26:01 +0100 (CET)
VBR-Info: md=sunet.se; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1416007561; bh=fm7RxTvH1kbCDC8jXWFQCg1KXakuc9hzPCGDq8+os4A=; h=Date:From:To:Subject; b=2oCBXkqsc+IdPPPbYbNc5OR+OsPiN22dF9u5mcY+iKapJxT8l0SDc1aQuw51NaNj1 QmY4v+7fFfkcHyhUGr/u2jF4I4s3NQAoOsTsl9mDYQuuTMqrxGDXTDLrBUZTtPp33/ C049wyGMQDhCUpPlvCtDD6LswJ0agqP512b+nzJA=
X-Footer: c3VuZXQuc2U=
Received: from [31.133.166.196] ([31.133.166.196]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for scim@ietf.org; Sat, 15 Nov 2014 00:25:58 +0100
Message-ID: <54668F83.10901@sunet.se>
Date: Sat, 15 Nov 2014 00:25:55 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "scim@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09Nfzq2e7 - 6fc7a2137076 - 20141115
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pvGdETvZgkoSb7uNTLTbw_HyzSY
Subject: [scim] Future of SCIM WG
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Nov 2014 23:26:10 -0000

Folk,

as of this week the core documents (schema, use-cases and api) are all
out of WGLC and will be written up by the chairs and submitted to the
IESG for publication.

In the meeting in HNL the following plan was discussed:

1. The SAML and LDAP profiles will be dropped from our charter because
of lack of interest from the community.

2. The SCIM is encouraged to submit proposals for extensions to
SCIM as individual drafts no later than 1 month before the next IETF
meeting in Dallas or we won't schedule a meeting for Dallas.

If you object to any of this, please speak up now.

	Cheers Leif & Morteza


From nobody Fri Nov 14 17:01:31 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D11ACD89 for ; Fri, 14 Nov 2014 17:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.235
X-Spam-Level: *
X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reHYlmbbh2fC for ; Fri, 14 Nov 2014 17:01:28 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8391A1A46 for ; Fri, 14 Nov 2014 17:01:28 -0800 (PST)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sAF11Qon002629 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Nov 2014 02:01:26 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sAF11MW9018447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Nov 2014 02:01:25 +0100 (CET)
VBR-Info: md=sunet.se; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1416013285; bh=OI5SDhYkgSp+UIeEU44cKolruUoH/Ae0SABWbwP4F0k=; h=Date:From:To:Subject; b=Hfw9x47fuOGmY5hswGLtFWUC7MpkwmSDvZ5rTRBR4cm+VURmDZh0Cu53bkdoFakLK umBenUtKgrFBSeROiYi0MXZy6v8B6yjlwP3UFp8qa2Eh7nglMIgErdAASHQea8DxgQ JChbCybaUZzM1mDhCCOVuMAmKRCc2hw5YmYwfV/8=
X-Footer: c3VuZXQuc2U=
Received: from [192.168.0.100] ([64.129.13.2]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for scim@ietf.org; Sat, 15 Nov 2014 02:01:22 +0100
Message-ID: <5466A5DE.9010008@sunet.se>
Date: Sat, 15 Nov 2014 02:01:18 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "scim@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09NfB1qE9 - ad955e0e1be9 - 20141115
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/7j6ITg5rMJRT_dVjrk76e3laBaE
Subject: [scim] scim meeting minutes
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Nov 2014 01:01:30 -0000

are now online


From nobody Fri Nov 14 20:21:13 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E11A0B76; Fri, 14 Nov 2014 20:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvIBeCL_H71s; Fri, 14 Nov 2014 20:20:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 543701A1A2C; Fri, 14 Nov 2014 20:20:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141115042052.31525.48940.idtracker@ietfa.amsl.com>
Date: Fri, 14 Nov 2014 20:20:52 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pqLwR8gkmc6WWO8vIWB2Ikg8-NQ
Cc: scim@ietf.org
Subject: [scim] I-D Action: draft-ietf-scim-core-schema-13.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Nov 2014 04:21:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF.

        Title           : System for Cross-Domain Identity Management: Core Schema
        Authors         : Phil Hunt
                          Kelly Grizzle
                          Erik Wahlstroem
                          Chuck Mortimore
	Filename        : draft-ietf-scim-core-schema-13.txt
	Pages           : 69
	Date            : 2014-11-14

Abstract:
   The System for Cross-Domain Identity Management (SCIM) specifications
   are designed to make identity management in cloud based applications
   and services easier.  The specification suite builds upon experience
   with existing schemas and deployments, placing specific emphasis on
   simplicity of development and integration, while applying existing
   authentication, authorization, and privacy models.  Its intent is to
   reduce the cost and complexity of user management operations by
   providing a common user schema and extension model, as well as
   binding documents to provide patterns for exchanging this schema
   using HTTP protocol.

   This document provides a platform neutral schema and extension model
   for representing users and groups and other resource types in JSON
   format.  This schema is intended for exchange and use with cloud
   service providers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-scim-core-schema-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Nov 14 20:31:06 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33D81A1AAC for ; Fri, 14 Nov 2014 20:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tXsojE2O6Bb for ; Fri, 14 Nov 2014 20:31:03 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3B51A0AF7 for ; Fri, 14 Nov 2014 20:31:02 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAF4V1Uf000430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Nov 2014 04:31:02 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAF4V1GF014650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 15 Nov 2014 04:31:01 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAF4V1Sw014637 for ; Sat, 15 Nov 2014 04:31:01 GMT
Received: from dhcp-8e0d.meeting.ietf.org (/31.133.142.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Nov 2014 20:31:00 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Phil Hunt 
In-Reply-To: <20141115042052.31525.48940.idtracker@ietfa.amsl.com>
Date: Fri, 14 Nov 2014 18:30:59 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <92D5459C-0DF1-4144-BCA8-91CFAF8C6E1B@oracle.com>
References: <20141115042052.31525.48940.idtracker@ietfa.amsl.com>
To: SCIM WG 
X-Mailer: Apple Mail (2.1990.1)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Pyd9TJ3-5X3M9w4EOkCISBckAy4
Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-13.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Nov 2014 04:31:05 -0000

As requested by the chairs, this update includes the 2 =E2=80=9Cnits=E2=80=
=9D that were mentioned in today=E2=80=99s F2F

1.  Correcting the examples which show =E2=80=9CexternalId=E2=80=9D as a =
multi-valued attribute (should be single-values)
2.  Clarify canonicalization processing for phoneNumbers and emails =
(Shelley=E2=80=99s proposed text during WGLC)

There is also a minor update to the API draft which includes adding a =
schema error to the =E2=80=9CinvalidValue=E2=80=9D error (also part of =
Shelley=E2=80=99s proposed text). It will likely be posted tomorrow.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 14, 2014, at 6:20 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the System for Cross-domain Identity =
Management Working Group of the IETF.
>=20
>        Title           : System for Cross-Domain Identity Management: =
Core Schema
>        Authors         : Phil Hunt
>                          Kelly Grizzle
>                          Erik Wahlstroem
>                          Chuck Mortimore
> 	Filename        : draft-ietf-scim-core-schema-13.txt
> 	Pages           : 69
> 	Date            : 2014-11-14
>=20
> Abstract:
>   The System for Cross-Domain Identity Management (SCIM) =
specifications
>   are designed to make identity management in cloud based applications
>   and services easier.  The specification suite builds upon experience
>   with existing schemas and deployments, placing specific emphasis on
>   simplicity of development and integration, while applying existing
>   authentication, authorization, and privacy models.  Its intent is to
>   reduce the cost and complexity of user management operations by
>   providing a common user schema and extension model, as well as
>   binding documents to provide patterns for exchanging this schema
>   using HTTP protocol.
>=20
>   This document provides a platform neutral schema and extension model
>   for representing users and groups and other resource types in JSON
>   format.  This schema is intended for exchange and use with cloud
>   service providers.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-scim-core-schema-13
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-13
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From nobody Mon Nov 17 16:17:02 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478C81ACF8B; Mon, 17 Nov 2014 16:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVJ1joyYT6N8; Mon, 17 Nov 2014 16:16:58 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C61ACF24; Mon, 17 Nov 2014 16:16:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141118001658.21422.82670.idtracker@ietfa.amsl.com>
Date: Mon, 17 Nov 2014 16:16:58 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/FlhxYwf-7iEWpQqgRIziMeNaKQc
Cc: scim@ietf.org
Subject: [scim] I-D Action: draft-ietf-scim-api-13.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Nov 2014 00:17:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF.

        Title           : System for Cross-Domain Identity Management: Protocol
        Authors         : Phil Hunt
                          Kelly Grizzle
                          Morteza Ansari
                          Erik Wahlstroem
                          Technology Nexus
                          Chuck Mortimore
	Filename        : draft-ietf-scim-api-13.txt
	Pages           : 78
	Date            : 2014-11-17

Abstract:
   The System for Cross-Domain Identity Management (SCIM) specification
   is an HTTP based protocol that makes managing identities in multi-
   domain scenarios easier to support through a standardized services.
   Examples include but are not limited to enterprise to cloud service
   providers, and inter-cloud based scenarios.  The specification suite
   seeks to build upon experience with existing schemas and deployments,
   placing specific emphasis on simplicity of development and
   integration, while applying existing authentication, authorization,
   and privacy models.  SCIM's intent is to reduce the cost and
   complexity of user management operations by providing a common user
   schema and extension model and a service protocol defined by this
   document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-scim-api/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-scim-api-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Nov 23 00:33:31 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E21A1B11 for ; Sun, 23 Nov 2014 00:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy62a8vG9B8I for ; Sun, 23 Nov 2014 00:33:28 -0800 (PST)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5111A1B0E for ; Sun, 23 Nov 2014 00:33:28 -0800 (PST)
Received: by mail-pd0-f175.google.com with SMTP id y10so8000485pdj.6 for ; Sun, 23 Nov 2014 00:33:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=1kA30XL0dT1FZ7qHpsalXivC0AFIVTKmod29P4M9asI=; b=myq2OhivtsmYjiLG5RSzTihmbGIkNlwvopyl2cZEPbEEdFKpN/39KIg/rLO45V22UL bTpCaR2oWgpZNndkXikBU0XABwilFDJW8qLFH/Yc2P/fcGmw5qJqxyEFR0+iz8Qi5dze ZdxdoGa6p/KmSQbG0do3Ht/KVlFzEBz3ScknvueFcK2Qa6yQ+HdGqbcJ+lYyO+kRWEBZ DS/rH7rd8cpuBQlKEK32a1bjVejsNWHh+ryUZC+b5tLQfeprkbQG/1qpq0JWGGcll0uq arLZDf/RLCV4c58KDIKUkO0OHqlPo7SWNh4FMTgNxdQ2bBiwiUsUqryGVevXeHnKQkjs aLJQ==
X-Received: by 10.66.227.103 with SMTP id rz7mr21927375pac.45.1416731607375; Sun, 23 Nov 2014 00:33:27 -0800 (PST)
Received: from [192.168.0.2] (87.125.30.125.dy.iij4u.or.jp. [125.30.125.87]) by mx.google.com with ESMTPSA id y3sm9214755pbt.44.2014.11.23.00.33.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Nov 2014 00:33:26 -0800 (PST)
From: Tomoya Usami 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Sun, 23 Nov 2014 17:33:24 +0900
To: scim@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/8Z4RdAnN7VdXiEqhi4I2nJKerFQ
Subject: [scim] Invalid JSON in example
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Nov 2014 08:33:29 -0000

Hi.

I found typo In draft-scim-core-schema-13 Section 3.2.1, It seems to be =
an invalid JSON data structure.

  PATCH /Users/2819c223-7f76-453a-919d-413861904646
  Host: example.com
  Accept: application/scim+json
  Content-Type: application/scim+json
  Authorization: Bearer h480djs93hd8
  If-Match: W/"a330bc54f0671c9"

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations":[{
      "op":"add",
      "value":"{
        "emails":[
          {
            "value":"babs@jensen.org",
            "type":"home"
          }
        ],
        "nickname":"Babs"
    }]
  }

In the above example has invalid "value" attribute's value.
It is probably intended as follows?

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
     "Operations": [{
        "op": "add",
        "value": {
          "emails": [
            {
              "value": "babs@jensen.org",
              "type": "home"
            }
          ],
          "nickname": "Babs"
        }
      }]
   }

--
Tomoya Usami


From nobody Sun Nov 23 08:33:07 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E501A0197 for ; Sun, 23 Nov 2014 08:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZvmko7J0a41 for ; Sun, 23 Nov 2014 08:33:00 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13381A0027 for ; Sun, 23 Nov 2014 08:33:00 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sANGWxUe026891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Nov 2014 16:32:59 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sANGWvAM016483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Nov 2014 16:32:58 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sANGWvwO020761; Sun, 23 Nov 2014 16:32:57 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Nov 2014 08:32:57 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Phil Hunt 
In-Reply-To: 
Date: Sun, 23 Nov 2014 08:32:56 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <72F3749C-04AB-4D39-9CB3-06E340D46D86@oracle.com>
References: 
To: Tomoya Usami 
X-Mailer: Apple Mail (2.1993)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kT5Qvlp84mrCmi3678fLRnqFUOE
Cc: scim@ietf.org
Subject: Re: [scim] Invalid JSON in example
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Nov 2014 16:33:03 -0000

Tomoya,

Yes, the quotation before the curly brace is wrong ( =E2=80=9C{ ).

Thanks,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 23, 2014, at 12:33 AM, Tomoya Usami  =
wrote:
>=20
> Hi.
>=20
> I found typo In draft-scim-core-schema-13 Section 3.2.1, It seems to =
be an invalid JSON data structure.
>=20
>  PATCH /Users/2819c223-7f76-453a-919d-413861904646
>  Host: example.com
>  Accept: application/scim+json
>  Content-Type: application/scim+json
>  Authorization: Bearer h480djs93hd8
>  If-Match: W/"a330bc54f0671c9"
>=20
>  {
>    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>    "Operations":[{
>      "op":"add",
>      "value":"{
>        "emails":[
>          {
>            "value":"babs@jensen.org",
>            "type":"home"
>          }
>        ],
>        "nickname":"Babs"
>    }]
>  }
>=20
> In the above example has invalid "value" attribute's value.
> It is probably intended as follows?
>=20
>   {
>     "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>     "Operations": [{
>        "op": "add",
>        "value": {
>          "emails": [
>            {
>              "value": "babs@jensen.org",
>              "type": "home"
>            }
>          ],
>          "nickname": "Babs"
>        }
>      }]
>   }
>=20
> --
> Tomoya Usami
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From nobody Mon Nov 24 11:34:58 2014
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDFA1A894A for ; Mon, 24 Nov 2014 11:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh0_9u70HEA9 for ; Mon, 24 Nov 2014 11:34:42 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3834C1A8716 for ; Mon, 24 Nov 2014 11:34:42 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAOJYexp009401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Nov 2014 19:34:41 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAOJYe7b009436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Nov 2014 19:34:40 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sAOJYdv2013330 for ; Mon, 24 Nov 2014 19:34:39 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Nov 2014 11:34:38 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9DA190B0-FAAF-430C-A380-CD9374044741"
Message-Id: <3307FC29-AF8C-4771-A39C-BB01A0573898@oracle.com>
Date: Mon, 24 Nov 2014 11:34:37 -0800
To: SCIM WG 
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/w32De_XJKDK1s1S5PWwvqHoXD88
Subject: [scim] Bug in SCIM API example
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Nov 2014 19:34:44 -0000

--Apple-Mail=_9DA190B0-FAAF-430C-A380-CD9374044741
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In the API document, Figure 3 and 4 should a root level search returning =
objects of differing resource types (Users and Groups).

Unfortunately the filter in Figure 3 restricts results to =
meta.resourceType as Users.  It should be Users or Groups.

Was:
{
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
     "attributes": ["displayName", "userName"],
     "filter":
       "(displayName sw \"smith\") and (meta.resourceType eq \"User\")",
     "startIndex": 1,
     "count": 10
   }

Should be:
{
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
     "attributes": ["displayName", "userName"],
     "filter":
       "(displayName sw \"smith\") and ((meta.resourceType eq =
\"User\=E2=80=9D)
         or (meta.resourceType eq \=E2=80=9DGroup\=E2=80=9D))",
     "startIndex": 1,
     "count": 10
   }

I will correct in the next update.

Also, thanks to Erik for the comments on Etag and delete. These should =
also be removed/clarified.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--Apple-Mail=_9DA190B0-FAAF-430C-A380-CD9374044741
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In the API document, Figure 3 and 4 should a root level =
search returning objects of differing resource types (Users and =
Groups).

Unfortunately=
 the filter in Figure 3 restricts results to meta.resourceType as Users. =
 It should be Users or Groups.

Was:
{
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
     "attributes": ["displayName", "userName"],
     "filter":
       "(displayName sw \"smith\") and (meta.resourceType eq \"User\")",
     "startIndex": 1,
     "count": 10
   }


Should =
be:
{
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
     "attributes": ["displayName", "userName"],
     "filter":
       "(displayName sw \"smith\") and ((meta.resourceType eq =
\"User\=E2=80=9D)
        =
 or (meta.resourceType eq \=E2=80=9DGroup\=E2=80=9D))",
     "startIndex": 1,
     "count": 10
   }


I will =
correct in the next update.

Also, thanks to Erik for the comments on Etag and delete. =
These should also be removed/clarified.






=

--Apple-Mail=_9DA190B0-FAAF-430C-A380-CD9374044741--