From nobody Tue Aug 2 13:48:24 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B86112D920 for ; Tue, 2 Aug 2016 13:48:22 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NNT-jz_Hvlvw for ; Tue, 2 Aug 2016 13:48:20 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DCD12D924 for ; Tue, 2 Aug 2016 13:48:16 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id b62so224293847iod.3 for ; Tue, 02 Aug 2016 13:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7extThXMtbWu6yo3k6758zy+BkKSquRxqFNedYgoSls=; b=fjEDazy/U/uKwlStEKrQmKdfB6EaezszZXJQsYQnaF/wMu/ZkUbF8Ao+6o3hEiYXTX Oa31RZju43uVX3ZuvRLJyzxnXQngbGshyB+vXyfam3KQyidnh14L5HI+U1XSjXVIX3Xb BHxy+qNemHQ8JS4JYFTyIsnDDveN9Vffkx0YJnEmuhGjG0b4bWbvQ8z8qT55A/kh94IF BVPc7AZYzGjWoYij8ESKiRoBZCHnFfbuk9hwDE5WxH0NZr1GvRlxgh40zg2g3ePmj6jo spCiNzpKcO/E9KMMshAaiAgdbkQNWav9DdOFZ9VGXD6i6+Frb7pNEGzpEYHMk/SpS7Cb g5+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7extThXMtbWu6yo3k6758zy+BkKSquRxqFNedYgoSls=; b=DmPulotDHKGOI3/6f0Ld9TYEgucwhIHqMsoIorWbVSfzz7x1M+i6pM5xanF+q70Ani PTGkW1/8+GsRNfhLYtd0ajO4F+Pme5psVUL2P1+5dG7j+oABRyTFHfmirLg0GWNHooxP bIXn9h1OorXTQnh7DF8FDMp3MIf2gQPhWa6qsGXcUjdILcypxgBpMq2ARFC0J1U21FIF 3aw6x+kGWW0048hpZW04i9fw+8bnsa4KiMfykoPK2mjNrJCxi7vblx9fFQsaDqA70bt4 XvbFbFtpse1VJh4KyT91zJae9OxHiWNgkhDWUs2ceCo1cVK/diNJ7rK7Oyz6GWuq2gVv Ojeg== X-Gm-Message-State: AEkooutej7N+YxuyI4PhjqJP8kw9QLItP8ZWaJp0ffanKYQYqsHb1l3WJgQFc31YpSqWjbM8yWlfQ4j7Ixa0xQ== X-Received: by 10.107.6.233 with SMTP id f102mr72857940ioi.55.1470170895610; Tue, 02 Aug 2016 13:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.41 with HTTP; Tue, 2 Aug 2016 13:48:15 -0700 (PDT) In-Reply-To: <18D912EC-FBF5-4914-943E-313A4B8948B1@oracle.com> References: <18D912EC-FBF5-4914-943E-313A4B8948B1@oracle.com> From: Shelley Date: Tue, 2 Aug 2016 15:48:15 -0500 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113ee4a6fdf94e05391cd53d Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] PATCH Response Status X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 20:48:22 -0000 --001a113ee4a6fdf94e05391cd53d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > The client can force the full response by including the attributes > parameter In order to get the full resource representation in the response, this would require consumers to explicitly list every single attribute in the "attributes" parameter. This may still be acceptable, but is certainly not very usable for consumers wishing to get the full response (issuing a subsequent GET would perhaps even be a better option). Note: of course a service provider might still refuse under its own access > rules. Can you please clarify this point? The spec seems to indicate that SPs MUST return a 200 when a PATCH is requested with the "attributes" parameter specified. On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt wrote: > Because of the issue you mention I would expect a lot are returning code > 204. The client can force the full response by including the attributes > parameter. Note: of course a service provider might still refuse under it= s > own access rules. > > Just as servers are required to be robust, we can expect that clients > should expect some variation from the servers on the response code and th= e > content of the response (the server isn=E2=80=99t obliged to accept data = as stated > 100%). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Jul 18, 2016, at 8:45 AM, Shelley wrote: > > The SCIM specification indicates that a server may return *either *a 200 > or 204 for successful PATCH requests, but *must *return 200 for PATCH > requests with the "attributes" parameter [1,2]. > > Our team's SCIM service provider implementation is currently deciding > which status code is the most appropriate to return. A 200 would provide > the most complete representation available and would provide consistency > regardless of the absence/presence of the "attributes" parameter. However= , > one of the most significant benefits of PATCH is the performance > improvements. For example, PATCH can prevent consumers from dealing with > extremely large group resources (in many cases, groups have thousands or > even tens-of-thousands of members); and likewise, the resources required = on > the server to process and/or return such large requests is significant. A > 204 response could therefore have significant performance benefits. > > What do other SCIM service providers return for successful PATCH requests= ? > Also, do SCIM consumers/clients properly handle the possibility for eithe= r > a 200 or 204 to be returned per the spec? > > [1] > http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-wi= th-patch > [2] https://tools.ietf.org/html/rfc7644#section-3.5.2 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --001a113ee4a6fdf94e05391cd53d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0The client can force the full response by including the attributes= parameter

In order to get the full resource representation in the response, thi= s would require consumers to explicitly list every single attribute in the = "attributes" parameter. This may still be acceptable, but is cert= ainly not very usable for consumers wishing to get the full response (issui= ng a subsequent GET would perhaps even be a better option).

Note: of course a service provide= r might still refuse under its own access rules.
Can you please clarify this point? The spec seems to= indicate that SPs MUST return a 200 when a PATCH is requested with the &qu= ot;attributes" parameter specified.

On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:
Because of the issue you mention I wou= ld expect a lot are returning code 204.=C2=A0 The client can force the full= response by including the attributes parameter.=C2=A0Note: of course a ser= vice provider might still refuse under its own access rules.

<= /div>
Just as servers are required to be robust, we can expect that cli= ents should expect some variation from the servers on the response code and= the content of the response (the server isn=E2=80=99t obliged to accept da= ta as stated 100%).


On Jul= 18, 2016, at 8:45 AM, Shelley <randomshelley@gmail.com> wrote:

=
The SCIM specifica= tion indicates that a server may return either a 200 or 204 for succ= essful PATCH requests, but must return 200 for PATCH requests with t= he "attributes" parameter [1,2].

Our team's SCIM servi= ce provider implementation is currently deciding which status code is the m= ost appropriate to return. A 200 would provide the most complete representa= tion available and would provide consistency regardless of the absence/pres= ence of the "attributes" parameter. However, one of the most sign= ificant benefits of PATCH is the performance improvements. For example, PAT= CH can prevent consumers from dealing with extremely large group resources = (in many cases, groups have thousands or even tens-of-thousands of members)= ; and likewise, the resources required on the server to process and/or retu= rn such large requests is significant. A 204 response could therefore have = significant performance benefits.

What do other SCIM service provide= rs return for successful PATCH requests? Also, do SCIM consumers/clients pr= operly handle the possibility for either a 200 or 204 to be returned per th= e spec?

[1] http://www.simplecl= oud.info/specs/draft-scim-api-01.html#edit-resource-with-patch
[2] <= a href=3D"https://tools.ietf.org/html/rfc7644#section-3.5.2" target=3D"_bla= nk">https://tools.ietf.org/html/rfc7644#section-3.5.2
_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim


--001a113ee4a6fdf94e05391cd53d-- From nobody Tue Aug 2 14:03:46 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4499412D0E6 for ; Tue, 2 Aug 2016 14:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 x_f0Xbn7tTul for ; Tue, 2 Aug 2016 14:03:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1A33D126FDC for ; Tue, 2 Aug 2016 14:03:42 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u72L3ePS011408 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2016 21:03:40 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u72L3ePi004871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2016 21:03:40 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u72L3bp5002238; Tue, 2 Aug 2016 21:03:37 GMT Received: from dhcp-whq-twvpn-3-vpnpool-10-159-238-155.vpn.oracle.com (/10.159.238.155) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2016 14:03:37 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_76100C83-14D1-44AB-9591-A6A6738597C2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Tue, 2 Aug 2016 14:03:35 -0700 Message-Id: <682DE7C0-0A67-4853-8196-00097B17190F@oracle.com> References: <18D912EC-FBF5-4914-943E-313A4B8948B1@oracle.com> To: Shelley X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] PATCH Response Status X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 21:03:44 -0000 --Apple-Mail=_76100C83-14D1-44AB-9591-A6A6738597C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. That is my interpretation as well. I agree, it is not an ideal = situation. It does same bandwidth and the results are given if the = client really really wants it. The problem with larger groups is that the bigger the get, we not only = have performance problems but we also have privacy and disclosure = problems. I think this will mean an eventual move towards = entitlement/role based access as user populations or group sizes grow. = I think also the mapping back and forth between user entry and groups is = also going to prove challenging. I think it is something we need to discuss. =20 =20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 2, 2016, at 1:48 PM, Shelley wrote: >=20 > The client can force the full response by including the attributes = parameter >=20 > In order to get the full resource representation in the response, this = would require consumers to explicitly list every single attribute in the = "attributes" parameter. This may still be acceptable, but is certainly = not very usable for consumers wishing to get the full response (issuing = a subsequent GET would perhaps even be a better option). >=20 > Note: of course a service provider might still refuse under its own = access rules. >=20 > Can you please clarify this point? The spec seems to indicate that SPs = MUST return a 200 when a PATCH is requested with the "attributes" = parameter specified. >=20 >=20 > On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt > wrote: > Because of the issue you mention I would expect a lot are returning = code 204. The client can force the full response by including the = attributes parameter. Note: of course a service provider might still = refuse under its own access rules. >=20 > Just as servers are required to be robust, we can expect that clients = should expect some variation from the servers on the response code and = the content of the response (the server isn=E2=80=99t obliged to accept = data as stated 100%). >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Jul 18, 2016, at 8:45 AM, Shelley > wrote: >>=20 >> The SCIM specification indicates that a server may return either a = 200 or 204 for successful PATCH requests, but must return 200 for PATCH = requests with the "attributes" parameter [1,2]. >>=20 >> Our team's SCIM service provider implementation is currently deciding = which status code is the most appropriate to return. A 200 would provide = the most complete representation available and would provide consistency = regardless of the absence/presence of the "attributes" parameter. = However, one of the most significant benefits of PATCH is the = performance improvements. For example, PATCH can prevent consumers from = dealing with extremely large group resources (in many cases, groups have = thousands or even tens-of-thousands of members); and likewise, the = resources required on the server to process and/or return such large = requests is significant. A 204 response could therefore have significant = performance benefits. >>=20 >> What do other SCIM service providers return for successful PATCH = requests? Also, do SCIM consumers/clients properly handle the = possibility for either a 200 or 204 to be returned per the spec? >>=20 >> [1] = http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-wit= h-patch = >> [2] https://tools.ietf.org/html/rfc7644#section-3.5.2 = >> _______________________________________________ >> 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=_76100C83-14D1-44AB-9591-A6A6738597C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes. That is my interpretation as well. I agree, it is not an = ideal situation. It does same bandwidth and the results are given if the = client really really wants it.

The problem with larger groups is that the = bigger the get, we not only have performance problems but we also have = privacy and disclosure problems.  I think this will mean an = eventual move towards entitlement/role based access as user populations = or group sizes grow.  I think also the mapping back and forth = between user entry and groups is also going to prove = challenging.

I = think it is something we need to discuss.  
 



On Aug 2, 2016, at 1:48 PM, Shelley <randomshelley@gmail.com> wrote:

 The client can force the full = response by including the attributes parameter

In order = to get the full resource representation in the response, this would = require consumers to explicitly list every single attribute in the = "attributes" parameter. This may still be acceptable, but is certainly = not very usable for consumers wishing to get the full response (issuing = a subsequent GET would perhaps even be a better option).
Note: of course a service provider might still = refuse under its own access rules.

Can you please clarify this point? The spec seems = to indicate that SPs MUST return a 200 when a PATCH is requested with = the "attributes" parameter specified.


On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt = <phil.hunt@oracle.com> = wrote:
Because of the issue you mention I would expect a lot are = returning code 204.  The client can force the full response by = including the attributes parameter. Note: of course a service = provider might still refuse under its own access rules.

Just as = servers are required to be robust, we can expect that clients should = expect some variation from the servers on the response code and the = content of the response (the server isn=E2=80=99t obliged to accept data = as stated 100%).

Phil

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




=

On Jul 18, 2016, at = 8:45 AM, Shelley <randomshelley@gmail.com> = wrote:

The SCIM = specification indicates that a server may return either = a 200 or 204 for successful PATCH requests, but must = return 200 for PATCH requests with the "attributes" parameter = [1,2].

Our team's SCIM service provider = implementation is currently deciding which status code is the most = appropriate to return. A 200 would provide the most complete = representation available and would provide consistency regardless of the = absence/presence of the "attributes" parameter. However, one of the most = significant benefits of PATCH is the performance improvements. For = example, PATCH can prevent consumers from dealing with extremely large = group resources (in many cases, groups have thousands or even = tens-of-thousands of members); and likewise, the resources required on = the server to process and/or return such large requests is significant. = A 204 response could therefore have significant performance benefits.

What do other SCIM service providers return = for successful PATCH requests? Also, do SCIM consumers/clients properly = handle the possibility for either a 200 or 204 to be returned per the = spec?

[1] http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-r= esource-with-patch
[2] https://tools.ietf.org/html/rfc7644#section-3.5.2
_______________________________________________
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

= --Apple-Mail=_76100C83-14D1-44AB-9591-A6A6738597C2-- From nobody Tue Aug 16 07:29:00 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31612D866 for ; Tue, 16 Aug 2016 07:28:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com 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 QihqHM1iJKN9 for ; Tue, 16 Aug 2016 07:28:56 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBA412D865 for ; Tue, 16 Aug 2016 07:28:56 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 74so124342796uau.0 for ; Tue, 16 Aug 2016 07:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=vGRAcTBjnB9p494hvBg1gQmtHVaCncOmBj1lLQ98yIA=; b=NLDrLSz93GAXw+NVXRaUMuG3RF4C+rjQ+IKXWVzpEI6J86AJqBPC9BYNYNts2oHoZV NnMLJZeMaZphh4b7OfBXYgn0oUnB6XW0vc4vRzoD2zuO0oEd8cMW7v8vZKAOSQI5ehOx oc7MFmjD2MQvFo1nAW/lg5YcDLBrMNczNI9HY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vGRAcTBjnB9p494hvBg1gQmtHVaCncOmBj1lLQ98yIA=; b=gHh2XSVVpDs55joGq9uCSXarvi7B5Q1Tk8b5C90o8pM765VWN4N61tkmZaX3ghTzx3 KEUK4XbO3Pu51B1/qJcGiF5SfpL6KQ6WwXFVhrLHTSN3UVZFNtopjtMhwZNiYknVeL1s jAkKC67roRYSDN19UiwcWqU/1apyXe8oCVWEMnn4PAzv1qeymgstpul6eRWDruM9V7d9 ar6xJ/z4QEcsuqw2KB6dlAUgkewljLfFkuWechWAAtWdkvAkGeCJiu+86P6e8gJKH0xa SbkJm0gs18iGgtyhjf7RUpcXpO/jeZXGAmefXfc3EgpgF/eRHL9yZ4PKFKpyMjiIFRA1 ak1g== X-Gm-Message-State: AEkoouuID5Pv0bS7ivzuls39eglZF3DmhFwD5KENu34dNwbXtLS0fKmV41rLH2BYzM5RRYxhmVFRHqUh+8qzXRGr X-Received: by 10.176.69.240 with SMTP id u103mr14361491uau.80.1471357735432; Tue, 16 Aug 2016 07:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.167 with HTTP; Tue, 16 Aug 2016 07:28:35 -0700 (PDT) From: Ian Glazer Date: Tue, 16 Aug 2016 10:28:35 -0400 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=94eb2c11ce6a28ab69053a312ba6 Archived-At: Subject: [scim] Cardinality X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:28:58 -0000 --94eb2c11ce6a28ab69053a312ba6 Content-Type: text/plain; charset=UTF-8 Hey gang - Coming out of the interop one thing that I'd definitely like to see is a way to represent cardinality in the schema. Case in point, the spec states that email is a multivalued attribute, but we only support a single email address. In order to comply with the spec, we have to represent it as mutlivalued and then we throw an error if someone tries to add more than one. Not optimal. I suggest a schema attribute of MaximumCardinality of type number. The number represents the maximum entries for a multivalued attribute. If not set, then it is implied there is no limit. -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --94eb2c11ce6a28ab69053a312ba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey gang -

Coming out of the interop on= e thing that I'd definitely like to see is a way to represent cardinali= ty in the schema. Case in point, the spec states that email is a multivalue= d attribute, but we only support a single email address. In order to comply= with the spec, we have to represent it as mutlivalued and then we throw an= error if someone tries to add more than one. Not optimal. I suggest a sche= ma attribute of MaximumCardinality of type number. The number represents th= e maximum entries for a multivalued attribute. If not set, then it is impli= ed there is no limit.

--
Ian Glazer=
Senior Director, Identity
+1 202 255 3166
@iglazer
--94eb2c11ce6a28ab69053a312ba6-- From nobody Tue Aug 16 07:32:44 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8812D84E for ; Tue, 16 Aug 2016 07:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com 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 qG2Qr_0288Gk for ; Tue, 16 Aug 2016 07:32:41 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E9412D84B for ; Tue, 16 Aug 2016 07:32:40 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id q128so147655478wma.1 for ; Tue, 16 Aug 2016 07:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BOESEans9IKiQ3j8KCla/MfmkowCQb6/tV3AG7/vLcY=; b=WkyA3IX3NkaFOPcCcO/YTOo1wWryCLBT5qWg0/blg80N4MF3Tt1Ri+2eR1IGGJjjZx G0SCZLd8h2s+AbbFE/WqwkO0He8cxbd/m2LzD//SHqsTgOVkv8e7nYfIRhZtzAf6ueCv Ctr43syf3yQa2La/dy4yZGBfGpvzd4PrVg1AEF2uK1tqGBxPWEfQbz8YLxqhgSwPDY3l +VKZ38BwU0pGXsQExAwhrJjAFpwKAtQhmZvEjsw/0hZWeZJ/pn83NnvEWohKTxuseHX4 0ahDNHsjZtuSFCNnNRXyoWDGdimrA1zi54Ei3etNMA7Pq+pIkmMQJjTcrasG4rx69gso hvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BOESEans9IKiQ3j8KCla/MfmkowCQb6/tV3AG7/vLcY=; b=PQshMf7lsY/1sVyf5fuy+50gQnNa8fMGRb/2mS5ND4sxfCfL+tzq7F+8E016QhxRhy nNtvL3ylD86OuZCet9o1m1gRWBG9l7aK4Xjd/jmdr1DBmDcV1ibZ6W7uL6e4mWtcaGzZ HRBtmN/s3EfHCrxoAtd5I4AhkaqWn/oEO3rU38h8pVAaUi8rYFirZOZj4yUm12FEzHeq WhFjtdDCHOmudhLQFrYJVKQfbwwMOc18JhX4b/tTghi70ocnOIwSeSMbqqYcpXszx3WL zCby6yilQq0wxSwm5ulXRcTIDfs1IfEnlTdEWHEFWn86SBcfZdaxcfPvYCeK3ceW+Ypd etAw== X-Gm-Message-State: AEkoouudd1i75r3LEtuyq22s0SAbeFlXtoTqS1ihydrgsJxo2t8TyT4Db1hJhrvm+Tb6VQ== X-Received: by 10.25.32.134 with SMTP id g128mr5775870lfg.87.1471357959153; Tue, 16 Aug 2016 07:32:39 -0700 (PDT) Received: from [10.0.0.136] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id 74sm849086ljb.36.2016.08.16.07.32.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 07:32:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B9400E10-B5D8-45A1-93C6-038E100AF8CD Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Tue, 16 Aug 2016 16:32:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ian Glazer Archived-At: Cc: "scim@ietf.org WG" Subject: Re: [scim] Cardinality X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:32:43 -0000 --Apple-Mail-B9400E10-B5D8-45A1-93C6-038E100AF8CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is somebody maintaining an issue list somewhere? Maybe dump the current rfcs= in github... Skickat fr=C3=A5n min iPhone > 16 aug. 2016 kl. 16:28 skrev Ian Glazer : >=20 > Hey gang - >=20 > Coming out of the interop one thing that I'd definitely like to see is a w= ay to represent cardinality in the schema. Case in point, the spec states th= at email is a multivalued attribute, but we only support a single email addr= ess. In order to comply with the spec, we have to represent it as mutlivalue= d and then we throw an error if someone tries to add more than one. Not opti= mal. I suggest a schema attribute of MaximumCardinality of type number. The n= umber represents the maximum entries for a multivalued attribute. If not set= , then it is implied there is no limit. >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-B9400E10-B5D8-45A1-93C6-038E100AF8CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is somebody maintaining an issue list s= omewhere? Maybe dump the current rfcs in github...

Skickat fr=C3=A5n m= in iPhone

16 aug. 2016 kl. 16:28 skrev Ian Glazer <iglazer@salesforce.com>:

Hey gang -

Coming out of the interop one thing that I'd definitely like to see is a w= ay to represent cardinality in the schema. Case in point, the spec states th= at email is a multivalued attribute, but we only support a single email addr= ess. In order to comply with the spec, we have to represent it as mutlivalue= d and then we throw an error if someone tries to add more than one. Not opti= mal. I suggest a schema attribute of MaximumCardinality of type number. The n= umber represents the maximum entries for a multivalued attribute. If not set= , then it is implied there is no limit.

--
Ian Glazer
Senior Director, Identity
+1 202 25= 5 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-B9400E10-B5D8-45A1-93C6-038E100AF8CD-- From nobody Tue Aug 16 07:54:02 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04EC12D860 for ; Tue, 16 Aug 2016 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 9SBmVRk26wBd for ; Tue, 16 Aug 2016 07:53:59 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E916A12D1CA for ; Tue, 16 Aug 2016 07:53:58 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id n128so34967331ith.1 for ; Tue, 16 Aug 2016 07:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sTdxgHFw9rFjlICgmAiStgfWRSUATKYDgP+mkAGaJjk=; b=SICrQT174IZBrjnkRnAm4Ee7SHk48jc0Fvl95OyeIvdAPU0uEccZuoqZ3JwGeX4TT2 xfmD48q4/0Vux7x/QaE06JHI0mq+QcNR+Ai/QEMCYl/4S3CG7rxv0Kxbt5RMcyHBbKio /evx1z2hZUQwcDKsZlcyri7Xvd5cZ6vJzUQBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sTdxgHFw9rFjlICgmAiStgfWRSUATKYDgP+mkAGaJjk=; b=j1SxEJkTInSMYrbq91ywWRM02oczEBuPVtNmlewKnemuhrMFcUA5U+KXLLZ/UU6XMM F6VB6dt7ZNwkZoSiFJKNpAPRszX9LysKjpxZHp3ptTA8k3Zm9NKcu/iOi0Al8W38MHI/ l1zOzUo+vnv5yeYB1JTO+4IiXhfuiV4lD0DPtWVE1n1kQ/Qo049XWiahZpaXSrKeIBYW agbyLFMosxEA35TEw1zHo7Al9EevqxJ+JwrWjbP/slAL7FIGoE+K+Pl+UpQAp2sV0TA7 UoIV9blM3+7W70q2eALNmUjBWh6SiMd4hv4pJ7WEmyshOzNgCiEhDhq6RiUjfyGiGpkt xDCw== X-Gm-Message-State: AEkoouvh3mj3Duters1cOjyCX9x53OFiQxXaNaK1m82iWfdan+OwWD3cVALQZWm2FO7GhaC8v6N3Wq7b4W6HTtzc X-Received: by 10.36.192.194 with SMTP id u185mr21857729itf.77.1471359234253; Tue, 16 Aug 2016 07:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.21 with HTTP; Tue, 16 Aug 2016 07:53:52 -0700 (PDT) In-Reply-To: References: From: Eric Fazendin Date: Tue, 16 Aug 2016 08:53:52 -0600 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=94eb2c05c7d47ec407053a31843a Archived-At: Cc: "scim@ietf.org WG" , Ian Glazer Subject: Re: [scim] Cardinality X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:54:01 -0000 --94eb2c05c7d47ec407053a31843a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have looked at the same issue, limiting emails to only a single value. We were thinking about doing it by enforcing uniqueness on and requiring the "type" subattribute and setting the canonicalValues for "type" to just "work". Obviously, this modifies the core schema, which slightly defeats the purpose of a standardized schema, but it's the best option we could find. [image: Ping Identity] Eric Fazendin Sr. Product Manager efazendin@pingidentity.com c: +1 303.895.9628 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] On Tue, Aug 16, 2016 at 8:32 AM, Leif Johansson wrote: > Is somebody maintaining an issue list somewhere? Maybe dump the current > rfcs in github... > > Skickat fr=C3=A5n min iPhone > > 16 aug. 2016 kl. 16:28 skrev Ian Glazer : > > Hey gang - > > Coming out of the interop one thing that I'd definitely like to see is a > way to represent cardinality in the schema. Case in point, the spec state= s > that email is a multivalued attribute, but we only support a single email > address. In order to comply with the spec, we have to represent it as > mutlivalued and then we throw an error if someone tries to add more than > one. Not optimal. I suggest a schema attribute of MaximumCardinality of > type number. The number represents the maximum entries for a multivalued > attribute. If not set, then it is implied there is no limit. > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > > _______________________________________________ > 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 > > --94eb2c05c7d47ec407053a31843a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have looked at the same issue, limiting emails to only = a single value.=C2=A0 We were thinking about doing it by enforcing uniquene= ss on and requiring the "type" subattribute and setting the canon= icalValues for "type" to just "work".

Obviously, this modifies the core schema, which slightly defeats the purp= ose of a standardized schema, but it's the best option we could find.




=09
3D"Ping =09
= Sr. Product Manager
efazendin@pingidentity.com
c: +1 303.895.9628
Connect with us: 3D"Glassdoor 3D"LinkedI= 3D"twitter 3D"face= =3D"youtube 3D"Google+ 3D"Blog =09

On Tue, Aug 16, 2016 at 8:32 AM, Leif Johans= son <leifj@mnt.se> wrote:
Is somebody maintaining an issue list somewhere? Maybe du= mp the current rfcs in github...

Skickat fr=C3=A5n min iPhone
<= div>

16 aug. 2016 kl. 16:28 skrev Ian Glazer <= iglazer@salesfo= rce.com>:

Hey gang -

Coming out of the interop one thing that I= 'd definitely like to see is a way to represent cardinality in the sche= ma. Case in point, the spec states that email is a multivalued attribute, b= ut we only support a single email address. In order to comply with the spec= , we have to represent it as mutlivalued and then we throw an error if some= one tries to add more than one. Not optimal. I suggest a schema attribute o= f MaximumCardinality of type number. The number represents the maximum entr= ies for a multivalued attribute. If not set, then it is implied there is no= limit.

--
Ian Glazer
Senior Director, Identity=
_______= ________________________________________
scim mailing = list
sci= m@ietf.org
https://www.ietf.org/mailman/listinfo/sci= m

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


--94eb2c05c7d47ec407053a31843a-- From nobody Tue Aug 16 08:22:36 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DA512D887 for ; Tue, 16 Aug 2016 08:22:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com 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 7Kvzdqx2WFpl for ; Tue, 16 Aug 2016 08:22:32 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B803312D893 for ; Tue, 16 Aug 2016 08:22:31 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 97so126929899uav.3 for ; Tue, 16 Aug 2016 08:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ye4GrcfffX3myAZEQr2rTXwXGZw7WWKJVBmJiA/zJMQ=; b=ftcjtOkJxo8MszkRdyRTAvIbjeZ0SofcWkAN8mUEunPcGJi4xvWtskcFyFtlXQbenz VD8cYJiGhgspxBg2twXjNo/2SZquXQBfeC5/+LoXyCrNqqRLLe5j6iABp18kL+E8jwwC nUFOZZC/AcP10r2GBKiTIte+uRcnpHBDr2rl4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ye4GrcfffX3myAZEQr2rTXwXGZw7WWKJVBmJiA/zJMQ=; b=gFntkhAQZU/K24z2NAk/wdrYtr5tt49Omhc/6ONaHxJqp3eZWcP23rklN5ycguTQuv 8h7thpCY81WhLxz8LI49muSuooUoIYHZ01RLIeUMDGKnCN0XvsNXFdjVPInobEzzpUG/ MqsGDOEp3jxbsNuUcj1ghr2sWztjpIIKGJmdy28vGEa0iZ0mz0LxZaiUci1WLmNhWUKZ +1Nzc6RqloF3tmyUIQA/u7L3Ik5LoDZBLq/tnB6+a5Q3B/SnFRHkeQYzsY4L0fM4q3/Y MoPFVI32sE77cAM1wxsPVBpbKTahAJArJFCrB/z/DSceQtWyTAaFubB31Z1JJq08Sr71 j1qw== X-Gm-Message-State: AEkooutpyjmXfB1lc3KDNXzE5HRrzViHVwaTOV4HsJ2165dN9vfqYx3bHhFK1W+y/0ehRep9LvbO0VqAd/Hgn+K1 X-Received: by 10.176.69.240 with SMTP id u103mr14502567uau.80.1471360950755; Tue, 16 Aug 2016 08:22:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.167 with HTTP; Tue, 16 Aug 2016 08:22:10 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Tue, 16 Aug 2016 11:22:10 -0400 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=94eb2c11ce6ace9f6a053a31eaa5 Archived-At: Cc: "scim@ietf.org WG" Subject: Re: [scim] Cardinality X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 15:22:33 -0000 --94eb2c11ce6ace9f6a053a31eaa5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It would be good to have at least one more WG meeting so that we can get a grab off all these items. It would also be good if said meeting was scheduled such that Shalini and the Google team could attend. On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson wrote: > Is somebody maintaining an issue list somewhere? Maybe dump the current > rfcs in github... > > Skickat fr=C3=A5n min iPhone > > 16 aug. 2016 kl. 16:28 skrev Ian Glazer : > > Hey gang - > > Coming out of the interop one thing that I'd definitely like to see is a > way to represent cardinality in the schema. Case in point, the spec state= s > that email is a multivalued attribute, but we only support a single email > address. In order to comply with the spec, we have to represent it as > mutlivalued and then we throw an error if someone tries to add more than > one. Not optimal. I suggest a schema attribute of MaximumCardinality of > type number. The number represents the maximum entries for a multivalued > attribute. If not set, then it is implied there is no limit. > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --94eb2c11ce6ace9f6a053a31eaa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be good to have at least one more WG meeting so t= hat we can get a grab off all these items. It would also be good if said me= eting was scheduled such that Shalini and the Google team could attend.

On Tue, Aug 16,= 2016 at 10:32 AM, Leif Johansson <leifj@mnt.se> wrote:
Is somebody maintaining an = issue list somewhere? Maybe dump the current rfcs in github...

Skick= at fr=C3=A5n min iPhone

16 aug. 2016 k= l. 16:28 skrev Ian Glazer <iglazer@salesforce.com>:

Hey gang -

Coming out o= f the interop one thing that I'd definitely like to see is a way to rep= resent cardinality in the schema. Case in point, the spec states that email= is a multivalued attribute, but we only support a single email address. In= order to comply with the spec, we have to represent it as mutlivalued and = then we throw an error if someone tries to add more than one. Not optimal. = I suggest a schema attribute of MaximumCardinality of type number. The numb= er represents the maximum entries for a multivalued attribute. If not set, = then it is implied there is no limit.

--
Ian Glazer
=
Senior Director, Identity
@iglazer
_______= ________________________________________
scim mailing = list
sci= m@ietf.org
https://www.ietf.org/mailman/listinfo/sci= m



--
Ian Glazer
Senior= Director, Identity
+1 202 255 3166
--94eb2c11ce6ace9f6a053a31eaa5-- From nobody Tue Aug 16 09:32:18 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84B512D87A for ; Tue, 16 Aug 2016 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 w1hPf7UDaomB for ; Tue, 16 Aug 2016 09:31:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3BA5A12D8B7 for ; Tue, 16 Aug 2016 09:31:39 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7GGVasv002895 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2016 16:31:38 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7GGVajZ032735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2016 16:31:36 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7GGVN58008489; Tue, 16 Aug 2016 16:31:30 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Aug 2016 09:31:22 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6FF9C96B-2288-4822-A5DF-50BEB93C590B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Tue, 16 Aug 2016 09:31:21 -0700 Message-Id: References: To: Ian Glazer X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Leif Johansson , "scim@ietf.org WG" Subject: Re: [scim] Cardinality X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 16:32:16 -0000 --Apple-Mail=_6FF9C96B-2288-4822-A5DF-50BEB93C590B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is some history here. When I raised this (because it broke LDAP = compatibility) the consensus was to support the vCARD and move schema = ahead of LDAP. That meant complex attributes and multi-values despite = LDAPs limitations. At least that was how I understood the consensus at = the time and the design inherited from SCIM 1.1. I note that there is pressure relief in the spec because a SP does not = have to retain multiple values (even though the schema says otherwise). = The SP is free to =E2=80=9Cedit=E2=80=9D the values it wants to keep. = The client should not expect that the service provider keeps any value = exactly as requested - that was part of the robust consideration as it = avoided a lot of complex alternatives requiring clients to have to = develop complex code by intensely interrogating schema and reacting to = each setting difference. Another example of this is telephone numbers = and email addresses where the SP is required to attempt to normalize = badly formed values =E2=80=94 which means the SP is actively modifying = data provided by the client. E.g. > Service providers SHOULD canonicalize the > value according to [RFC5321 = ], e.g., "bjensen@example.com" = instead > of "bjensen@EXAMPLE.COM". >=20 > Service providers SHOULD canonicalize the > value according to [RFC3966 = ] format, when appropriate. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 16, 2016, at 8:22 AM, Ian Glazer = wrote: >=20 > It would be good to have at least one more WG meeting so that we can = get a grab off all these items. It would also be good if said meeting = was scheduled such that Shalini and the Google team could attend. >=20 > On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson > wrote: > Is somebody maintaining an issue list somewhere? Maybe dump the = current rfcs in github... >=20 > Skickat fr=C3=A5n min iPhone >=20 > 16 aug. 2016 kl. 16:28 skrev Ian Glazer >: >=20 >> Hey gang - >>=20 >> Coming out of the interop one thing that I'd definitely like to see = is a way to represent cardinality in the schema. Case in point, the spec = states that email is a multivalued attribute, but we only support a = single email address. In order to comply with the spec, we have to = represent it as mutlivalued and then we throw an error if someone tries = to add more than one. Not optimal. I suggest a schema attribute of = MaximumCardinality of type number. The number represents the maximum = entries for a multivalued attribute. If not set, then it is implied = there is no limit. >>=20 >> --=20 >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer = _____________________________________________= __ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer = _____________________________________________= __ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = --Apple-Mail=_6FF9C96B-2288-4822-A5DF-50BEB93C590B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
There is some history here. When I raised = this (because it broke LDAP compatibility) the consensus was to support = the vCARD and move schema ahead of LDAP. That meant complex attributes = and multi-values despite LDAPs limitations.  At least that was how = I understood the consensus at the time and the design inherited from = SCIM 1.1.

I = note that there is pressure relief in the spec because a SP does not = have to retain multiple values (even though the schema says otherwise). = The SP is free to =E2=80=9Cedit=E2=80=9D the values it wants to keep. = The client should not expect that the service provider keeps any value = exactly as requested - that was part of the robust consideration as it = avoided a lot of complex alternatives requiring clients to have to = develop complex code by intensely interrogating schema and reacting to = each setting difference.  Another example of this is telephone = numbers and email addresses where the SP is required to attempt to = normalize badly formed values =E2=80=94 which means the SP is actively = modifying data provided by the client.  E.g.
Service providers =
SHOULD canonicalize the
      value according to [RFC5321], e.g., "bjensen@example.com" instead
      of "bjensen@EXAMPLE.COM".

Service providers SHOULD canonicalize the
      value according to [RFC3966] format, when =
appropriate.

Phil






On Aug 16, 2016, at 8:22 AM, Ian Glazer <iglazer@salesforce.com> wrote:

It would be good to have at =
least one more WG meeting so that we can get a grab off all these items. =
It would also be good if said meeting was scheduled such that Shalini =
and the Google team could attend.

On Tue, Aug 16, 2016 at 10:32 AM, Leif =
Johansson <leifj@mnt.se> wrote:
Is somebody maintaining an issue list =
somewhere? Maybe dump the current rfcs in github...

Skickat fr=C3=A5n min iPhone

16 aug. 2016 kl. 16:28 skrev =
Ian Glazer <iglazer@salesforce.com>:

Hey gang -

Coming out of the interop one thing =
that I'd definitely like to see is a way to represent cardinality in the =
schema. Case in point, the spec states that email is a multivalued =
attribute, but we only support a single email address. In order to =
comply with the spec, we have to represent it as mutlivalued and then we =
throw an error if someone tries to add more than one. Not optimal. I =
suggest a schema attribute of MaximumCardinality of type number. The =
number represents the maximum entries for a multivalued attribute. If =
not set, then it is implied there is no limit.

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer
_______________________________________________
scim =
mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



-- 
Ian Glazer
Senior Director, Identity
+1 202 255 =
3166
@iglazer
_______________________________________________
scim mailing =
list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
=

--Apple-Mail=_6FF9C96B-2288-4822-A5DF-50BEB93C590B--


From nobody Tue Aug 16 11:38:02 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5912D14A for ; Tue, 16 Aug 2016 11:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sailpoint.onmicrosoft.com
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 dCTXIpNzYlZa for ; Tue, 16 Aug 2016 11:37:57 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0104.outbound.protection.outlook.com [104.47.41.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A8812B074 for ; Tue, 16 Aug 2016 11:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sailpoint.onmicrosoft.com; s=selector1-sailpoint-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BzvWkAhKyp1k1wjTd2RFewXR/hQZD9jfvwWT4mvbcd4=; b=I84ApCwnozkS66d68ENy9CfF8UqJdWt8xIcssyBA+KmK9Xft4eI9zwxwsaVbBbJ+oO1i3nUedCQASH5ue2aOyUp+WUA1goHCjGugwXHR1V/PX6RTw+04HJZOYksH04gmDfVb4Bzmtx/mfpTvRGlEhgtOgL7kyXutm2Nk4/jUvyg=
Received: from CY1PR04MB2363.namprd04.prod.outlook.com (10.167.10.143) by CY1PR04MB2362.namprd04.prod.outlook.com (10.167.10.142) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 16 Aug 2016 18:37:55 +0000
Received: from CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) by CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) with mapi id 15.01.0557.022; Tue, 16 Aug 2016 18:37:55 +0000
From: Kelly Grizzle 
To: Ian Glazer , Leif Johansson 
Thread-Topic: [scim] Cardinality
Thread-Index: AQHR98qNr1GyhjnQtEGamB86hONBcqBLpnyAgAAN2ACAADWqMA==
Date: Tue, 16 Aug 2016 18:37:54 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; 
x-originating-ip: [2605:ed00:f006:716:c89f:ec1a:400c:df7c]
x-ms-office365-filtering-correlation-id: 7511599f-1d35-4ce3-84a0-08d3c6046ffc
x-microsoft-exchange-diagnostics: 1; CY1PR04MB2362; 6:hI1240yVoov41Ljbjn0yHBNgODQ9t1uSBHAV5Co1bipuxz6SIKPYh9EbTHNeNKFUxLqtgFZ72MSYq3OELbSlLB02lI3Ge3LjWaqI5ZJ7yPH3M+/5R77dSbUAJWNzQ+u1wy2HFOOW83OUXqpZBmHG1rnoMjtROLUUdGYs9LZxLAbDIxyQyRZraIMQlYdsgmwoEPWl2erjqUV9Lslm8NUdBwyZG9DS6pA9uUWhdCX3Mtm+sPQWzlGxj5XSDergn6YDbBnUT7LOJgqh+dE9xjueTkZTC/aZ62elnNyFmeApV6A=; 5:p3txRaoVr8vAjKmRkO1T+nY3k2438TJCw30CQ6Ptxy0tWoYU6rjjLK47Q9rMLUV9D1EzpxogxaXn52tTPevk+i/ZR3bcxPahTf9Dm5kUMWtuekufcScWt9MdYSy5W4Yxr8XS2gbxtQafcXQjao2pAAgC3RXzul22N5Xn1GR0IZA=; 24:Cg7ZaSFHfgY6vL5dAL2ZS9TTbm5x33ywf39rfEhshwhuf2yFcQA//SeYmWABBq7kUIkoSDTTnDg2ZhRICJordh2L4hMU+6tzCXnMh72Tp2E=; 7:UaNEmQU9wza9bInFFUKN1tSx97ajnOUgwaGn1CRd9YgzX8h8H86FZcwG0OsZp5/VrOaIGYoir3eMpKGhGUD7AfJYM2aneiMKOrhABjIy4/hKeYfEFUCko/pRA0M+mZA+CHav9BwxIasiaVx6EdOG2jyr4iZCeagBqH+OGVahgYVCFc2SioaiUXFCM5pfIVjE2k7QDghvNzBDBldxLfmP0PcOjIMghLzWD3vDXncPwxv0lpZHVVspFaOIrC3rutWY
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR04MB2362;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(31418570063057)(206333022235701)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:CY1PR04MB2362; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR04MB2362; 
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(189002)(199003)(99286002)(2950100001)(77096005)(2900100001)(19580405001)(15975445007)(87936001)(50986999)(33656002)(76176999)(76576001)(105586002)(54356999)(86362001)(19580395003)(16236675004)(6116002)(106116001)(5002640100001)(102836003)(7736002)(19625215002)(7906003)(10400500002)(11100500001)(790700001)(7696003)(7846002)(8936002)(92566002)(586003)(101416001)(81166006)(4326007)(68736007)(74316002)(9686002)(81156014)(19617315012)(3280700002)(8676002)(2906002)(3660700001)(122556002)(19609705001)(106356001)(97736004)(189998001)(5001770100001)(19300405004)(61000200001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR04MB2362; H:CY1PR04MB2363.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR04MB2363D3608ED922EB08B6C679E2130CY1PR04MB2363namp_"
MIME-Version: 1.0
X-OriginatorOrg: sailpoint.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 18:37:54.5897 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR04MB2362
Archived-At: 
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] Cardinality
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 18:38:00 -0000

--_000_CY1PR04MB2363D3608ED922EB08B6C679E2130CY1PR04MB2363namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBhdCBsZWFzdCBoYXZlIHNvbWUgd2F5IHRvIGluZGljYXRl
IGlmIGFuIGF0dHJpYnV0ZSBoYXMgdGhlc2UgdHlwZXMgb2YgbGltaXRhdGlvbnMgKGxpa2UgSWFu
IHNhaWQg4oCmIHRoZSBzY2hlbWEgaXMgYSBwZXJmZWN0IHBsYWNlIGZvciB0aGlzKS4gIFRoZSBx
dWVzdGlvbiBhYm91dCB3aGF0IHRvIGRvIGlmIHNvbWVvbmUgZG9lc27igJl0IGFkaGVyZSB0byB0
aGlzIGFsc28gZGVzZXJ2ZXMgc29tZSBkaXNjdXNzaW9uLg0KDQpJIGhhdmUgYSBsaXN0IG9mIGlz
c3Vlcy90aG91Z2h0cyBmcm9tIHRoZSBpbnRlcm9wIHRoYXQgSSB3YXMgc3VwcG9zZWQgdG8gcHV0
IG9uIHRoZSBsaXN0LCBidXQgaGF2ZSBub3QgaGFkIGEgY2hhbmNlIHRvIHlldC4gIFNvcnJ5IQ0K
DQpXaGF04oCZcyB0aGUgYmVzdCB3YXkgdG8gY2FwdHVyZSB0aGVzZT8gIFRoZSBTQ0lNIGlzc3Vl
IHRyYWNrZXI/ICBTdGFydCBhIGdpdGh1YiBwcm9qZWN0IGZvciB0cmFja2luZz8gIEp1c3QgY2hh
c2UgdGhlbSBkb3duIG92ZXIgZW1haWw/ICBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYW5vdGhl
ciBtZWV0aW5nIHdoZXJlIHdlIGNhbiBmaWd1cmUgb3V0IGhvdyB0byB0YWNrbGUgdGhlc2UuDQoN
Ci0tS2VsbHkNCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIElhbiBHbGF6ZXINClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxNiwgMjAxNiAxMDoy
MiBBTQ0KVG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+DQpDYzogc2NpbUBpZXRmLm9y
ZyBXRyA8c2NpbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2NpbV0gQ2FyZGluYWxpdHkNCg0K
SXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGF0IGxlYXN0IG9uZSBtb3JlIFdHIG1lZXRpbmcgc28g
dGhhdCB3ZSBjYW4gZ2V0IGEgZ3JhYiBvZmYgYWxsIHRoZXNlIGl0ZW1zLiBJdCB3b3VsZCBhbHNv
IGJlIGdvb2QgaWYgc2FpZCBtZWV0aW5nIHdhcyBzY2hlZHVsZWQgc3VjaCB0aGF0IFNoYWxpbmkg
YW5kIHRoZSBHb29nbGUgdGVhbSBjb3VsZCBhdHRlbmQuDQoNCk9uIFR1ZSwgQXVnIDE2LCAyMDE2
IGF0IDEwOjMyIEFNLCBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAbW50LnNlPG1haWx0bzpsZWlmakBt
bnQuc2U+PiB3cm90ZToNCklzIHNvbWVib2R5IG1haW50YWluaW5nIGFuIGlzc3VlIGxpc3Qgc29t
ZXdoZXJlPyBNYXliZSBkdW1wIHRoZSBjdXJyZW50IHJmY3MgaW4gZ2l0aHViLi4uDQoNClNraWNr
YXQgZnLDpW4gbWluIGlQaG9uZQ0KDQoxNiBhdWcuIDIwMTYga2wuIDE2OjI4IHNrcmV2IElhbiBH
bGF6ZXIgPGlnbGF6ZXJAc2FsZXNmb3JjZS5jb208bWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5j
b20+PjoNCkhleSBnYW5nIC0NCg0KQ29taW5nIG91dCBvZiB0aGUgaW50ZXJvcCBvbmUgdGhpbmcg
dGhhdCBJJ2QgZGVmaW5pdGVseSBsaWtlIHRvIHNlZSBpcyBhIHdheSB0byByZXByZXNlbnQgY2Fy
ZGluYWxpdHkgaW4gdGhlIHNjaGVtYS4gQ2FzZSBpbiBwb2ludCwgdGhlIHNwZWMgc3RhdGVzIHRo
YXQgZW1haWwgaXMgYSBtdWx0aXZhbHVlZCBhdHRyaWJ1dGUsIGJ1dCB3ZSBvbmx5IHN1cHBvcnQg
YSBzaW5nbGUgZW1haWwgYWRkcmVzcy4gSW4gb3JkZXIgdG8gY29tcGx5IHdpdGggdGhlIHNwZWMs
IHdlIGhhdmUgdG8gcmVwcmVzZW50IGl0IGFzIG11dGxpdmFsdWVkIGFuZCB0aGVuIHdlIHRocm93
IGFuIGVycm9yIGlmIHNvbWVvbmUgdHJpZXMgdG8gYWRkIG1vcmUgdGhhbiBvbmUuIE5vdCBvcHRp
bWFsLiBJIHN1Z2dlc3QgYSBzY2hlbWEgYXR0cmlidXRlIG9mIE1heGltdW1DYXJkaW5hbGl0eSBv
ZiB0eXBlIG51bWJlci4gVGhlIG51bWJlciByZXByZXNlbnRzIHRoZSBtYXhpbXVtIGVudHJpZXMg
Zm9yIGEgbXVsdGl2YWx1ZWQgYXR0cmlidXRlLiBJZiBub3Qgc2V0LCB0aGVuIGl0IGlzIGltcGxp
ZWQgdGhlcmUgaXMgbm8gbGltaXQuDQoNCi0tDQpJYW4gR2xhemVyDQpTZW5pb3IgRGlyZWN0b3Is
IElkZW50aXR5DQorMSAyMDIgMjU1IDMxNjY8dGVsOiUyQjElMjAyMDIlMjAyNTUlMjAzMTY2Pg0K
QGlnbGF6ZXI8aHR0cHM6Ly90d2l0dGVyLmNvbS9pZ2xhemVyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGll
dGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zY2ltDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERpcmVjdG9yLCBJ
ZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3aXR0ZXIuY29tL2ln
bGF6ZXI+DQo=

--_000_CY1PR04MB2363D3608ED922EB08B6C679E2130CY1PR04MB2363namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgYXQgbGVhc3QgaGF2
ZSBzb21lIHdheSB0byBpbmRpY2F0ZSBpZiBhbiBhdHRyaWJ1dGUgaGFzIHRoZXNlIHR5cGVzIG9m
IGxpbWl0YXRpb25zIChsaWtlIElhbiBzYWlkIOKApiB0aGUgc2NoZW1hIGlzIGEgcGVyZmVjdCBw
bGFjZSBmb3IgdGhpcykuJm5ic3A7IFRoZSBxdWVzdGlvbg0KIGFib3V0IHdoYXQgdG8gZG8gaWYg
c29tZW9uZSBkb2VzbuKAmXQgYWRoZXJlIHRvIHRoaXMgYWxzbyBkZXNlcnZlcyBzb21lIGRpc2N1
c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBhIGxpc3Qgb2YgaXNzdWVzL3Rob3VnaHRzIGZy
b20gdGhlIGludGVyb3AgdGhhdCBJIHdhcyBzdXBwb3NlZCB0byBwdXQgb24gdGhlIGxpc3QsIGJ1
dCBoYXZlIG5vdCBoYWQgYSBjaGFuY2UgdG8geWV0LiAmbmJzcDtTb3JyeSE8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+V2hhdOKAmXMgdGhlIGJlc3Qgd2F5IHRvIGNhcHR1cmUgdGhlc2U/Jm5ic3A7IFRoZSBTQ0lN
IGlzc3VlIHRyYWNrZXI/Jm5ic3A7IFN0YXJ0IGEgZ2l0aHViIHByb2plY3QgZm9yIHRyYWNraW5n
PyZuYnNwOyBKdXN0IGNoYXNlIHRoZW0gZG93biBvdmVyIGVtYWlsPyZuYnNwOyBJdCB3b3VsZCBi
ZSBnb29kIHRvIGhhdmUgYW5vdGhlciBtZWV0aW5nDQogd2hlcmUgd2UgY2FuIGZpZ3VyZSBvdXQg
aG93IHRvIHRhY2tsZSB0aGVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LS1LZWxseTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2NpbSBbbWFpbHRvOnNjaW0t
Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIEdsYXplcjxicj4NCjxi
PlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTYgMTA6MjIgQU08YnI+DQo8Yj5Ubzo8
L2I+IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBtbnQuc2UmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBz
Y2ltQGlldGYub3JnIFdHICZsdDtzY2ltQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW3NjaW1dIENhcmRpbmFsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGF0IGxlYXN0IG9uZSBtb3JlIFdHIG1lZXRp
bmcgc28gdGhhdCB3ZSBjYW4gZ2V0IGEgZ3JhYiBvZmYgYWxsIHRoZXNlIGl0ZW1zLiBJdCB3b3Vs
ZCBhbHNvIGJlIGdvb2QgaWYgc2FpZCBtZWV0aW5nIHdhcyBzY2hlZHVsZWQgc3VjaCB0aGF0IFNo
YWxpbmkgYW5kIHRoZSBHb29nbGUgdGVhbSBjb3VsZCBhdHRlbmQuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAxNiwgMjAxNiBhdCAxMDoz
MiBBTSwgTGVpZiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsZWlmakBtbnQuc2UiIHRh
cmdldD0iX2JsYW5rIj5sZWlmakBtbnQuc2U8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHNvbWVi
b2R5IG1haW50YWluaW5nIGFuIGlzc3VlIGxpc3Qgc29tZXdoZXJlPyBNYXliZSBkdW1wIHRoZSBj
dXJyZW50IHJmY3MgaW4gZ2l0aHViLi4uPGJyPg0KPGJyPg0KU2tpY2thdCBmcsOlbiBtaW4gaVBo
b25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KMTYgYXVnLiAy
MDE2IGtsLiAxNjoyOCBza3JldiBJYW4gR2xhemVyICZsdDs8YSBocmVmPSJtYWlsdG86aWdsYXpl
ckBzYWxlc2ZvcmNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlnbGF6ZXJAc2FsZXNmb3JjZS5jb208
L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhleSBnYW5nIC08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkNvbWluZyBvdXQgb2YgdGhlIGludGVyb3Agb25lIHRoaW5nIHRoYXQgSSdk
IGRlZmluaXRlbHkgbGlrZSB0byBzZWUgaXMgYSB3YXkgdG8gcmVwcmVzZW50IGNhcmRpbmFsaXR5
IGluIHRoZSBzY2hlbWEuIENhc2UgaW4gcG9pbnQsIHRoZSBzcGVjIHN0YXRlcyB0aGF0IGVtYWls
IGlzIGEgbXVsdGl2YWx1ZWQgYXR0cmlidXRlLCBidXQgd2Ugb25seSBzdXBwb3J0IGEgc2luZ2xl
IGVtYWlsIGFkZHJlc3MuIEluIG9yZGVyDQogdG8gY29tcGx5IHdpdGggdGhlIHNwZWMsIHdlIGhh
dmUgdG8gcmVwcmVzZW50IGl0IGFzIG11dGxpdmFsdWVkIGFuZCB0aGVuIHdlIHRocm93IGFuIGVy
cm9yIGlmIHNvbWVvbmUgdHJpZXMgdG8gYWRkIG1vcmUgdGhhbiBvbmUuIE5vdCBvcHRpbWFsLiBJ
IHN1Z2dlc3QgYSBzY2hlbWEgYXR0cmlidXRlIG9mIE1heGltdW1DYXJkaW5hbGl0eSBvZiB0eXBl
IG51bWJlci4gVGhlIG51bWJlciByZXByZXNlbnRzIHRoZSBtYXhpbXVtIGVudHJpZXMgZm9yDQog
YSBtdWx0aXZhbHVlZCBhdHRyaWJ1dGUuIElmIG5vdCBzZXQsIHRoZW4gaXQgaXMgaW1wbGllZCB0
aGVyZSBpcyBubyBsaW1pdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SWFuIEdsYXplcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+U2VuaW9yIERpcmVjdG9yLCBJZGVudGl0eTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0idGVsOiUyQjEl
MjAyMDIlMjAyNTUlMjAzMTY2IiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxIDIwMiAyNTUgMzE2Njwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh
IGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplciIgdGFyZ2V0PSJfYmxhbmsiPkBpZ2xh
emVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08
L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs
bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xh
emVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
ZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgMjAyIDI1NSAzMTY2PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3R3aXR0
ZXIuY29tL2lnbGF6ZXIiIHRhcmdldD0iX2JsYW5rIj5AaWdsYXplcjwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_CY1PR04MB2363D3608ED922EB08B6C679E2130CY1PR04MB2363namp_--


From nobody Tue Aug 16 12:23:01 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1012D0B2 for ; Tue, 16 Aug 2016 12:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com
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 12ENgX10Aia9 for ; Tue, 16 Aug 2016 12:22:57 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6425D12B00B for ; Tue, 16 Aug 2016 12:22:57 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id i5so188931788wmg.0 for ; Tue, 16 Aug 2016 12:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EuxtS9IQxwSNynPjmExTJCN9u6zrY6Bxulgs1nTiu3Q=; b=TKHI7jF7IlwG+XSNWTeqZirb3oqGV0IXlRoggCwy+S6ovMwX/DpjjhBQxPmp+D6TRZ /Gxz2AeoGVdHTiLu5cueGwg++N2mBZ5W1AzYQ6HvfhxBY12la+UYdcHikjUkbVP/9ZaA tm1vK+SgBR09P4gawPsMxw4u63z2TjoMnpue/p6RbNPu5kg0CSrFNMQcKHKdbPDojn5a 5KGYQBeQpNJSuwXj6exvXMFoasMAkBZzaZK6hOPpNEBf1S/a8ohZyaXAMIEPr1ThuwHP ErWSyFlEC6QaC9xvV2H8RCZZwUGtUc6rQR4EsLcEe5pnmGt/NXnQsFZiz+mw+BDNNMwH UNHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EuxtS9IQxwSNynPjmExTJCN9u6zrY6Bxulgs1nTiu3Q=; b=DqIdeZDUoe51AYjBA/iiIlNwunbVoXJzqAl1pNQkO+cUgKcaY6bw3l58S5jvdsUCjx m4H4lw1B+EQPRY4XCOIRT3RSZ7IBkHGLi5LsTxV+Hos969PPVOfpWHUuGLMJlNK9H8Kq 61y9x3YSJffjHexawik2S4LWhmgIsGjC23GbTMkLb3oACxwmZ4KEP4FlPBTSjsaVwOtk c5YZ1Y9r3/dBrLiOZpaV4Flgejiw+KfnZeoBByNpZkZEnYVTrM6PXA5MrBOGVOHnirQV KIiUCo+/EMdX4cWdjr7B1bunCaBLda3ryVtWLk0Cnlw/nmDW2I2VxT06VfWN1sS8OWUA EfpA==
X-Gm-Message-State: AEkoout+7IH2pMTSzNL2spV7S/ba5y/ehNXUlGQ8Fof3zrrSnM6Ur87eJzNys/cYq0iPsg==
X-Received: by 10.25.89.2 with SMTP id n2mr6589050lfb.208.1471375375753; Tue, 16 Aug 2016 12:22:55 -0700 (PDT)
Received: from [10.0.0.136] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id g11sm1010665lji.25.2016.08.16.12.22.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 12:22:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-4336287F-437E-45C7-93BB-5A77B3FFCE24
Mime-Version: 1.0 (1.0)
From: Leif Johansson 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: 
Date: Tue, 16 Aug 2016 21:22:54 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   
To: Ian Glazer 
Archived-At: 
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] Cardinality
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 19:23:00 -0000

--Apple-Mail-4336287F-437E-45C7-93BB-5A77B3FFCE24
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Skickat fr=C3=A5n min iPhone

> 16 aug. 2016 kl. 17:22 skrev Ian Glazer :
>=20
> It would be good to have at least one more WG meeting so that we can get a=
 grab off all these items. It would also be good if said meeting was schedul=
ed such that Shalini and the Google team could attend.

The WG is already closed down but that doesn't matter since you can still do=
 errata.=20

My suggestion is still to gather up issues and do one big revision instead o=
f a piecemeal approach.

>=20
>> On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson  wrote:
>> Is somebody maintaining an issue list somewhere? Maybe dump the current r=
fcs in github...
>>=20
>> Skickat fr=C3=A5n min iPhone
>>=20
>>> 16 aug. 2016 kl. 16:28 skrev Ian Glazer :
>>>=20
>>> Hey gang -
>>>=20
>>> Coming out of the interop one thing that I'd definitely like to see is a=
 way to represent cardinality in the schema. Case in point, the spec states t=
hat email is a multivalued attribute, but we only support a single email add=
ress. In order to comply with the spec, we have to represent it as mutlivalu=
ed and then we throw an error if someone tries to add more than one. Not opt=
imal. I suggest a schema attribute of MaximumCardinality of type number. The=
 number represents the maximum entries for a multivalued attribute. If not s=
et, then it is implied there is no limit.
>>>=20
>>> --=20
>>> Ian Glazer
>>> Senior Director, Identity
>>> +1 202 255 3166
>>> @iglazer
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>=20
>=20
>=20
> --=20
> Ian Glazer
> Senior Director, Identity
> +1 202 255 3166
> @iglazer

--Apple-Mail-4336287F-437E-45C7-93BB-5A77B3FFCE24
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Skickat fr=C3=A5n min iPhone

16 aug. 2016 kl. 17:22 skrev Ian Glazer <iglazer@salesforce.com>:

It would be good to have at least on=
e more WG meeting so that we can get a grab off all these items. It would al=
so be good if said meeting was scheduled such that Shalini and the Google te=
am could attend.

The WG is alrea=
dy closed down but that doesn't matter since you can still do errata. <=
/div>

My suggestion is still to gather up issues and do o=
ne big revision instead of a piecemeal approach.


On Tue=
, Aug 16, 2016 at 10:32 AM, Leif Johansson <leifj@mnt.se> wrote:
Is somebody maintainin=
g an issue list somewhere? Maybe dump the current rfcs in github...

S=
kickat fr=C3=A5n min iPhone

16 aug. 201=
6 kl. 16:28 skrev Ian Glazer <iglazer@salesforce.com>:

Hey gang -

Coming out o=
f the interop one thing that I'd definitely like to see is a way to represen=
t cardinality in the schema. Case in point, the spec states that email is a m=
ultivalued attribute, but we only support a single email address. In order t=
o comply with the spec, we have to represent it as mutlivalued and then we t=
hrow an error if someone tries to add more than one. Not optimal. I suggest a=
 schema attribute of MaximumCardinality of type number. The number represent=
s the maximum entries for a multivalued attribute. If not set, then it is im=
plied there is no limit.

-- 
Ian Glazer
Senior Dire=
ctor, Identity




________=
_______________________________________
scim mailing li=
st
scim@i=
etf.org
https://www.ietf.org/mailman/listinfo/scim=




-- 
Ian Glazer
Senior Director,=
 Identity
+1 202 255 3166




=

--Apple-Mail-4336287F-437E-45C7-93BB-5A77B3FFCE24--


From nobody Tue Aug 16 12:23:54 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C912D0B2 for ; Tue, 16 Aug 2016 12:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com
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 vOgO_SZm4nt7 for ; Tue, 16 Aug 2016 12:23:49 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFFF12B00B for ; Tue, 16 Aug 2016 12:23:49 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id f65so159699739wmi.0 for ; Tue, 16 Aug 2016 12:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pqO5qZpeqgLvKTACSLTMf3prO0hEnKUUCsPD8ClnOM=; b=sV94hQp9p4+e+Foxl8Twj06r0scP6HJ+gp9bb0O6aGdtqvlMx4FMpOJH9wqA/ksYKy Qto43R0vqxPqR01SsVZvh3M/RsI0ly11QJJ6BZCVJiuv/8kxVx26WT3r3lqG28N1Qwzw QDh7fa6w2/8U0Dr/p5FGrYKG5mZ5DPenLMYfjhSvGvIV1LUIiFUkwqTIcrCWiEcL98ti WtH9Y7nBTUnuilY3CNsKYbhPebtHLcUCWniA42xHO29SwIPkBGYPa4WS55XjZ/G9EWkk O0sr3b9fIeuCoN5gunrPOHE1tWvtof2u++wOEUQzjNsNcannElZrxrp8NfaWqLwCBRUw 73Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pqO5qZpeqgLvKTACSLTMf3prO0hEnKUUCsPD8ClnOM=; b=W4VOWu6jSCnxo6InBGliCpgvXhUUj5D/Rp7VxzzyDwCS2d4EAFOz62N7xs33gNYLEP zkk7AwDZJRDWYPeLSsI6+gVCmfrUgkFPTTwo+WKgkF46WAVH0LCB8Q1ZtvLn11w9J2Hq THnoXsS8zVRKkJbwW77A7vVb0yUVP88KonHPcWnIuJcB9iJcJU7gDBtol0n21uhlillS TR7r1+DAYTjgMu3O9z2+Z0xn3mce7Cu6o4epTKp43GEU2oi+pxwGtR/rPWr97mac5su5 HnoQXTcpj/Fiwq+R9uu0ilkZdx4WtjKtSI5G90HkkFh1JHKHnfrh5qKQBfLThRxwB2N7 K+Pg==
X-Gm-Message-State: AEkoousIJ7DPkRFPT/kPqYFUQ4lNguNEb/b9oX1/W38vvbZF8eF7xGU7EZQdH8y80qpehw==
X-Received: by 10.25.157.146 with SMTP id g140mr5990776lfe.172.1471375427643;  Tue, 16 Aug 2016 12:23:47 -0700 (PDT)
Received: from [10.0.0.136] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id 98sm1004606lja.37.2016.08.16.12.23.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 12:23:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-F18FFC55-1DCC-4E55-94AE-934FDB8F8ADC
Mime-Version: 1.0 (1.0)
From: Leif Johansson 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: 
Date: Tue, 16 Aug 2016 21:23:45 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5756FC73-84F0-4564-8546-29A93A8373FA@mnt.se>
References:    
To: Kelly Grizzle 
Archived-At: 
Cc: "scim@ietf.org WG" , Ian Glazer 
Subject: Re: [scim] Cardinality
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 19:23:52 -0000

--Apple-Mail-F18FFC55-1DCC-4E55-94AE-934FDB8F8ADC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Skickat fr=C3=A5n min iPhone

> 16 aug. 2016 kl. 20:37 skrev Kelly Grizzle :
>=20
> I agree that we should at least have some way to indicate if an attribute h=
as these types of limitations (like Ian said =E2=80=A6 the schema is a perfe=
ct place for this).  The question about what to do if someone doesn=E2=80=99=
t adhere to this also deserves some discussion.
> =20
> I have a list of issues/thoughts from the interop that I was supposed to p=
ut on the list, but have not had a chance to yet.  Sorry!
> =20
> What=E2=80=99s the best way to capture these?  The SCIM issue tracker?  St=
art a github project for tracking?  Just chase them down over email?  It wou=
ld be good to have another meeting where we can figure out how to tackle the=
se.

+1 for github issues

> =20
> --Kelly
> =20
> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer
> Sent: Tuesday, August 16, 2016 10:22 AM
> To: Leif Johansson 
> Cc: scim@ietf.org WG 
> Subject: Re: [scim] Cardinality
> =20
> It would be good to have at least one more WG meeting so that we can get a=
 grab off all these items. It would also be good if said meeting was schedul=
ed such that Shalini and the Google team could attend.
> =20
> On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson  wrote:
> Is somebody maintaining an issue list somewhere? Maybe dump the current rf=
cs in github...
>=20
> Skickat fr=C3=A5n min iPhone
>=20
> 16 aug. 2016 kl. 16:28 skrev Ian Glazer :
>=20
> Hey gang -
> =20
> Coming out of the interop one thing that I'd definitely like to see is a w=
ay to represent cardinality in the schema. Case in point, the spec states th=
at email is a multivalued attribute, but we only support a single email addr=
ess. In order to comply with the spec, we have to represent it as mutlivalue=
d and then we throw an error if someone tries to add more than one. Not opti=
mal. I suggest a schema attribute of MaximumCardinality of type number. The n=
umber represents the maximum entries for a multivalued attribute. If not set=
, then it is implied there is no limit.
> =20
> --
> Ian Glazer
> Senior Director, Identity
> +1 202 255 3166
> @iglazer
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>=20
>=20
> =20
> --
> Ian Glazer
> Senior Director, Identity
> +1 202 255 3166
> @iglazer

--Apple-Mail-F18FFC55-1DCC-4E55-94AE-934FDB8F8ADC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Skickat fr=C3=A5n min iPhone

16 aug. 2016 kl. 20:37 skrev Kelly Grizzle <kelly.grizzle@sailpoint.com>:

<=
/div>










I agree that we should at least have some way to indi=
cate if an attribute has these types of limitations (like Ian said =E2=80=A6=
 the schema is a perfect place for this).  The question
 about what to do if someone doesn=E2=80=99t adhere to this also deserves so=
me discussion.


 


I have a list of issues/thoughts from the interop tha=
t I was supposed to put on the list, but have not had a chance to yet.  =
;Sorry!


 


What=E2=80=99s the best way to capture these?  T=
he SCIM issue tracker?  Start a github project for tracking?  Just=
 chase them down over email?  It would be good to have another meeting
 where we can figure out how to tackle these.

+1 for github issues



 


--Kelly


 


From: scim [mailto:scim-bounces@ietf.org]
On Behalf Of Ian Glazer

Sent: Tuesday, August 16, 2016 10:22 AM

To: Leif Johansson <leifj@mnt.se>

Cc: scim@ietf.org WG <scim@ietf.org>

Subject: Re: [scim] Cardinality


 




It would be good to have at least one more WG meeting=
 so that we can get a grab off all these items. It would also be good if sai=
d meeting was scheduled such that Shalini and the Google team could attend.<=
o:p>






 




On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson <=
leifj@mnt.se> wrote=
:








Is somebody maintaining an issue list somewhere? Mayb=
e dump the current rfcs in github...



Skickat fr=C3=A5n min iPhone












16 aug. 2016 kl. 16:28 skrev Ian Glazer <iglazer@salesforce.com>:










Hey gang -




 






Coming out of the interop one thing that I'd definite=
ly like to see is a way to represent cardinality in the schema. Case in poin=
t, the spec states that email is a multivalued attribute, but we only suppor=
t a single email address. In order
 to comply with the spec, we have to represent it as mutlivalued and then we=
 throw an error if someone tries to add more than one. Not optimal. I sugges=
t a schema attribute of MaximumCardinality of type number. The number repres=
ents the maximum entries for
 a multivalued attribute. If not set, then it is implied there is no limit.<=
o:p>






 




-- 








Ian Glazer






Senior Director, Identity




























_______________________________________________

scim mailing list

scim@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/scim





















 




-- 








Ian Glazer






Senior Director, Identity






+1 202 255 3166















=

--Apple-Mail-F18FFC55-1DCC-4E55-94AE-934FDB8F8ADC--


From nobody Wed Aug 17 19:20:36 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4059D12D587 for ; Wed, 17 Aug 2016 19:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.037
X-Spam-Level: 
X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.247, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 XkCz8fPFJctb for ; Wed, 17 Aug 2016 19:20:31 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83466128E18 for ; Wed, 17 Aug 2016 19:20:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 06900B41BD for ; Thu, 18 Aug 2016 02:20:31 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:organization:subject:subject:to:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1471486830; x=1472350831; bh=2kEpO8UaGu ubIev6nreTSGC/tlmJ3Xz7M7c11Kt/4Ic=; b=XjNdpJPiqR7dMuyo2YHlkRY+uf rMSR5WjqIEFZFwI6uJ515gXyfxbqlfPW7yPFB3X/jd00qlgFDFvop8eQt2Ugsjyu OUGA52AlvGPon+z+K1zHJC45A+JqWYZAm0BeVPmjt1cvsbZox7oq8l3F0EYom5Oz DZsn7i5nqCb/omX8Q=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqX3rf33hsZM for ; Thu, 18 Aug 2016 02:20:30 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id C5156B41B3 for ; Thu, 18 Aug 2016 02:20:30 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 17 Aug 2016 21:20:30 -0500
From: Mike Schwartz 
To: scim@ietf.org
Organization: Gluu
Message-ID: 
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Subject: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 02:20:33 -0000

SCIM gurus,

We decided to define a new resource type named "FidoDevice".

If you're curious about the design:  
https://github.com/GluuFederation/oxAuth/issues/226

- Mike

  -------------------------------------
Michael Schwartz
Gluu
http://gluu.org


From nobody Thu Aug 18 09:10:36 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1E12DC83; Thu, 18 Aug 2016 09:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.448
X-Spam-Level: 
X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yJ7GsrTn3YFy; Thu, 18 Aug 2016 09:10:25 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DAC1E12DC58; Thu, 18 Aug 2016 09:10:24 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7IGANHg003306 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:10:23 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7IGANpe003390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:10:23 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u7IGAM4R024231; Thu, 18 Aug 2016 16:10:22 GMT
Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Aug 2016 09:10:22 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735"
Message-Id: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Date: Thu, 18 Aug 2016 09:10:20 -0700
References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com>
To: id-event@ietf.org
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" , "scim@ietf.org WG" 
Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 16:10:29 -0000

--Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Draft 03 has been published.

This includes editorial clarifications to:
* Define the outer layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs =
embedded JSON as =E2=80=9Cpayload=E2=80=9D
* Clarify that only a single event should be conveyed plus optional =
extensions.
* General edits to improve readability
* Register the =E2=80=9Cevents=E2=80=9D claim as a  JWT attribute (see =
IANA considerations)

Many thanks to Mike and Sarah and who contributed significant editorial =
feedback.

Phil

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






> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hunt-idevent-token-03.txt
> Date: August 18, 2016 at 9:03:35 AM PDT
> To: "Michael B. Jones" , "William Denniss" =
, "Phil Hunt" , "Morteza =
Ansari" , "Michael Jones" 
>=20
>=20
> A new version of I-D, draft-hunt-idevent-token-03.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>=20
> Name:		draft-hunt-idevent-token
> Revision:	03
> Title:		Security Event Token (SET)
> Document date:	2016-08-18
> Group:		Individual Submission
> Pages:		16
> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-03.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-idevent-token/
> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-idevent-token-03
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-03
>=20
> Abstract:
>   This specification defines the Security Event token, which may be
>   distributed via a protocol such as HTTP.  The Security Event Token
>   (SET) specification profiles the JSON Web Token (JWT) and may be
>   optionally signed and/or encrypted.  A SET describes a statement of
>   fact that may be shared by an event publisher with event =
subscribers.
>=20
>=20
>=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
> The IETF Secretariat
>=20


--Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Draft 03 has been published.

This includes editorial clarifications =
to:
* Define the outer layer as a SET =
=E2=80=9Cenvelope=E2=80=9D, vs embedded JSON as =E2=80=9Cpayload=E2=80=9D<=
/div>
* Clarify that only a single event should be =
conveyed plus optional extensions.
* General edits =
to improve readability
* Register the =E2=80=9Cevents=
=E2=80=9D claim as a  JWT attribute (see IANA =
considerations)

Many thanks to Mike and Sarah and who contributed significant =
editorial feedback.










Begin forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
New Version =
Notification for draft-hunt-idevent-token-03.txt
Date: =
August 18, 2016 at 9:03:35 AM =
PDT
To: =
"Michael B. Jones" <mbj@microsoft.com>, =
"William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-03.txt
has been successfully submitted by Phil Hunt and posted to =
the
IETF repository.

Name:		=
draft-hunt-idevent-token
Revision:	03
Title:=
		=
Security Event Token (SET)
Document date:	=
2016-08-18
Group:		Individual Submission
Pages:=
		=
16
URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0=
3.txt
Status: =
        https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<=
br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-03
Diff: =
          https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-03=


Abstract:
 =
  This specification defines the Security Event token, which =
may be
   distributed via a protocol such as =
HTTP.  The Security Event Token
   (SET) =
specification profiles the JSON Web Token (JWT) and may be
 =
  optionally signed and/or encrypted.  A SET describes a =
statement of
   fact that may be shared by an =
event publisher with event subscribers.




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.

The IETF Secretariat


=

--Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735--


From nobody Thu Aug 18 09:11:52 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E609B12D0B7 for ; Thu, 18 Aug 2016 09:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.448
X-Spam-Level: 
X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9iGRP8Beck8M for ; Thu, 18 Aug 2016 09:11:48 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 A236D12DA29 for ; Thu, 18 Aug 2016 09:11:48 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7IGBjrY005001 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:11:46 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7IGBixP007021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:11:45 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7IGBheD016239; Thu, 18 Aug 2016 16:11:44 GMT
Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Aug 2016 09:11:43 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_002E8DDF-2D66-4F96-8429-DC605DE8ED27"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: 
Date: Thu, 18 Aug 2016 09:11:42 -0700
Message-Id: <4AF4BFC3-9903-4959-9B67-79B403E1E77D@oracle.com>
References: 
To: Mike Schwartz 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: scim@ietf.org
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2016 16:11:51 -0000

--Apple-Mail=_002E8DDF-2D66-4F96-8429-DC605DE8ED27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mike,

There is an IANA registration process where you can register your schema =
URI once you are happy it is ready.

Phil

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






> On Aug 17, 2016, at 7:20 PM, Mike Schwartz  wrote:
>=20
>=20
> SCIM gurus,
>=20
> We decided to define a new resource type named "FidoDevice".
>=20
> If you're curious about the design:  =
https://github.com/GluuFederation/oxAuth/issues/226
>=20
> - Mike
>=20
> -------------------------------------
> Michael Schwartz
> Gluu
> http://gluu.org
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_002E8DDF-2D66-4F96-8429-DC605DE8ED27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Mike,

There=
 is an IANA registration process where you can register your schema URI =
once you are happy it is ready.








On Aug 17, 2016, at 7:20 PM, Mike Schwartz <mike@gluu.org> =
wrote:


SCIM gurus,

We =
decided to define a new resource type named "FidoDevice".

If you're curious about the design:  https://github.com/GluuFederation/oxAuth/issues/226

- Mike

 =
-------------------------------------
Michael Schwartz
Gluu
http://gluu.org

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

=

--Apple-Mail=_002E8DDF-2D66-4F96-8429-DC605DE8ED27--


From nobody Fri Aug 19 07:42:05 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1F12DB1F; Fri, 19 Aug 2016 07:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 Xdzv636ueztv; Fri, 19 Aug 2016 07:42:01 -0700 (PDT)
Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADC812DB12; Fri, 19 Aug 2016 07:42:00 -0700 (PDT)
Received: from [192.168.1.3] ([79.100.92.246]) by p3plsmtpa06-07.prod.phx3.secureserver.net with  id Z2hx1t0015JvR27012hyRt; Fri, 19 Aug 2016 07:42:00 -0700
To: Phil Hunt , id-event@ietf.org
References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com> <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <1aa732d5-4f97-2c58-f4ee-37947761fc95@connect2id.com>
Date: Fri, 19 Aug 2016 17:41:56 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070008030103030807080802"
Archived-At: 
Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" , "scim@ietf.org WG" 
Subject: Re: [scim] [Openid-specs-ab] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 14:42:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms070008030103030807080802
Content-Type: multipart/alternative;
 boundary="------------E4C99828B441BB83D126E6F5"

This is a multi-part message in MIME format.
--------------E4C99828B441BB83D126E6F5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I just went through the new version, the text has a much better
structure and clarity now.

Thanks everyone!


On 18/08/16 19:10, Phil Hunt via Openid-specs-ab wrote:
> Draft 03 has been published.
>
> This includes editorial clarifications to:
> * Define the outer layer as a SET =93envelope=94, vs embedded JSON as =93=
payload=94
> * Clarify that only a single event should be conveyed plus optional ext=
ensions.
> * General edits to improve readability
> * Register the =93events=94 claim as a  JWT attribute (see IANA conside=
rations)
>
> Many thanks to Mike and Sarah and who contributed significant editorial=
 feedback.
>
> Phil
>
> @independentid
> www.independentid.com phil.hunt@oracle.c=
om 
>
>
>
>
>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-hunt-idevent-token-03.txt
>> Date: August 18, 2016 at 9:03:35 AM PDT
>> To: "Michael B. Jones" , "William Denniss" , "Phil Hunt" , "Morteza Ansari" , "Michael Jones" 
>>
>>
>> A new version of I-D, draft-hunt-idevent-token-03.txt
>> has been successfully submitted by Phil Hunt and posted to the
>> IETF repository.
>>
>> Name:		draft-hunt-idevent-token
>> Revision:	03
>> Title:		Security Event Token (SET)
>> Document date:	2016-08-18
>> Group:		Individual Submission
>> Pages:		16
>> URL:            https://www.ietf.org/internet-drafts/draft-hunt-ideven=
t-token-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-to=
ken/
>> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-0=
3
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent=
-token-03
>>
>> Abstract:
>>   This specification defines the Security Event token, which may be
>>   distributed via a protocol such as HTTP.  The Security Event Token
>>   (SET) specification profiles the JSON Web Token (JWT) and may be
>>   optionally signed and/or encrypted.  A SET describes a statement of
>>   fact that may be shared by an event publisher with event subscribers=
=2E
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com


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


  
    
  
  
    
I just went through the new version, the text has a much better
      structure and clarity now.

    
Thanks everyone!

    

    

    
On 18/08/16 19:10, Phil Hunt via
      Openid-specs-ab wrote:

    

    

      
Draft 03 has been published.

This includes editorial clarifications to:
* Define the outer layer as a SET =93envelope=94, vs embedded JSON as =93=
payload=94
* Clarify that only a single event should be conveyed plus optional exten=
sions.
* General edits to improve readability
* Register the =93events=94 claim as a  JWT attribute (see IANA considera=
tions)

Many thanks to Mike and Sarah and who contributed significant editorial f=
eedback.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>=
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>







      

        
Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for draft-hunt-idevent-token-03.txt
Date: August 18, 2016 at 9:03:35 AM PDT
To: "Michael B. Jones" <mbj@microsoft.com>, "William Denniss" <wde=
nniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Mor=
teza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj=
@microsoft.com>


A new version of I-D, draft-hunt-idevent-token-03.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name:		draft-hunt-idevent-token
Revision:	03
Title:		Security Event Token (SET)
Document date:	2016-08-18
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.=
org/internet-drafts/draft-hunt-idevent-token-03.txt
Status:         https://datatracker.ietf.or=
g/doc/draft-hunt-idevent-token/
Htmlized:       https://tools.ietf.org/html/dr=
aft-hunt-idevent-token-03
Diff:           https://www.ietf.org/r=
fcdiff?url2=3Ddraft-hunt-idevent-token-03

Abstract:
  This specification defines the Security Event token, which may be
  distributed via a protocol such as HTTP.  The Security Event Token
  (SET) specification profiles the JSON Web Token (JWT) and may be
  optionally signed and/or encrypted.  A SET describes a statement of
  fact that may be shared by an event publisher with event subscribers.




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

The IETF Secretariat



      

      



      

      

      

      
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab@lists.openid.net
http://lists.openid.net/mailman/listinfo/open=
id-specs-ab


    

    

    
--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com

  


--------------E4C99828B441BB83D126E6F5--

--------------ms070008030103030807080802
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib
fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP
qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax
OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry
wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7
r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU
fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu
JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+
4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ
4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA
m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjA4MTkxNDQxNTZaMC8GCSqGSIb3DQEJBDEiBCA8tzZw3Jmu7Wd6FtTcBuOLVqand33G
Zt836F0G8/tCtzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQAyrsq+6ME5
Zm+6gcHUwjY7mwwduJSmPmngH0af9E8pAFTNT2HB83AVcj2HU8ONLO3++QkMC8U942qg8+/J
yBoJ+w35WRqPpM8Rd1eaBmBw6YFJAcr5tSUIbjEU/JEo7NSFR+lNkhqBdBY4lv1GLfP/44wc
IFdaGPXQlWIVy3ZGuBVJlFGgTvJB3lCclz31n1XZvxVDHDZ86L6rPaBmLTTUPD7eivyRdQtm
cYyXSfWKBEqImHZBAuTIwI8gBjnezmlgD1n7wlpnarG8dXKJv3aHz9XnwAKobIEzUIluVCug
zpcGO6Uoi/n+O8doB1y5flt6Kv4FF+IaVkfk/BgCgZ4cAAAAAAAA
--------------ms070008030103030807080802--


From nobody Fri Aug 19 14:56:53 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BE712D66A for ; Fri, 19 Aug 2016 14:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level: 
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 foK6P3VfAs6R for ; Fri, 19 Aug 2016 14:56:50 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D4812D618 for ; Fri, 19 Aug 2016 14:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=939; q=dns/txt; s=iport; t=1471643810; x=1472853410; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8ao5qAK6ayn3CimRQ2KwidZZzyOWeCYTark3SriJGvY=; b=iWqoqlzaU/c5q4bhzko4tA//86rxVPmbi3/KwepDlcUoi1IaCyM8zzBW RNbB4+zEvjqM2AAt4/Qx6zJOMyAKccsD0zIpOjz0jRTY4K+ukKr7vqZ42 Pe16ApbmRqFlqJmwUEpDc3cR5C1/a9HjOw3LOihlPB0JKJm5ZMCzWStNF 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAgB8gLdX/4MNJK1eg0RWfAe3aYF9J?= =?us-ascii?q?IUvSgKBazgUAgEBAQEBAQFeJ4RfAQUBAWwbAgEIRicLJQIEARKIMQ66cQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEehiuETYobBYgrhi2KbwGGH4h+gjmNE5A0AR42g3pwh?= =?us-ascii?q?i5/AQEB?=
X-IronPort-AV: E=Sophos;i="5.28,546,1464652800"; d="scan'208";a="311582620"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2016 21:56:34 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7JLuYtZ021453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Aug 2016 21:56:34 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 19 Aug 2016 16:56:33 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Fri, 19 Aug 2016 16:56:33 -0500
From: "Morteza Ansari (moransar)" 
To: Mike Schwartz , "scim@ietf.org" 
Thread-Topic: [scim] FIDO Cred Mgt via SCIM
Thread-Index: AQHR+PcfjCdKY88iHk+U7QE1PGsGsaBQtaGA
Date: Fri, 19 Aug 2016 21:56:33 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.42.127]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5867ACA8F3FE914DAC16BB03A7B3709A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 21:56:52 -0000

Hi Mike,

Have you considered doing a device object and an extension for Fido bits?
I think device is a generic object that would be helpful to define and
extend in a reasonably common ways.  I am willing to work on that if you
are interested. We had talked about this a few times but didn=B9t have
concrete examples beyond some of the things each of us had done
individually.


Cheers,
Morteza

On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
 wrote:

>
>SCIM gurus,
>
>We decided to define a new resource type named "FidoDevice".
>
>If you're curious about the design:
>https://github.com/GluuFederation/oxAuth/issues/226
>
>- Mike
>
>  -------------------------------------
>Michael Schwartz
>Gluu
>http://gluu.org
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>https://www.ietf.org/mailman/listinfo/scim


From nobody Sat Aug 20 09:02:14 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BEB12D0E0 for ; Sat, 20 Aug 2016 09:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.037
X-Spam-Level: 
X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.247, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 u0DExW2yCZ8l for ; Sat, 20 Aug 2016 09:02:09 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7669212B00C for ; Sat, 20 Aug 2016 09:02:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id B1C33B41F4 for ; Sat, 20 Aug 2016 16:02:08 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1471708928; x=1472572929; bh=a7rpX4iSQn s/5N+SOw1vz3k3AtmKVbMrRu56vlEzvvA=; b=jutr+u0K0saLfYGlUjrJQZP99Z 0x+wC7+O+zgh0LVldnzfDsQM3WInSkLWVICBiL8si6QOffOScN73S2/gRzFlqzed zs8//CHevVDNeCOkME4EaV0ZrIWdvN2Yz8wz+Stmr0Tc6j/A2/dYL2pgE9bpzxDZ 5SxdENGFAdRSi5nAA=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez2R3nfmoQrq for ; Sat, 20 Aug 2016 16:02:08 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 65D4EB41B3; Sat, 20 Aug 2016 16:02:08 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 20 Aug 2016 11:02:08 -0500
From: Mike Schwartz 
To: "Morteza Ansari (moransar)" 
Organization: Gluu
In-Reply-To: 
References:  
Message-ID: 
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Cc: scim@ietf.org
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 16:02:13 -0000

Morteza,

Thanks for the offer. We'd definitely appreciate any help or feedback.

I was wondering about Device. I was concerned that my idea for a device 
was something like a smart phone, and FIDO devices are more limited. We 
ended up deciding to define a new resource type called "FidoDevice"

More details of the design and requirements were documented on this 
github issue:
   https://github.com/GluuFederation/oxAuth/issues/226

We want this to support the U2F, UAF and FIDO2 devices of a person.

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org

On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
> Hi Mike,
> 
> Have you considered doing a device object and an extension for Fido 
> bits?
> I think device is a generic object that would be helpful to define and
> extend in a reasonably common ways.  I am willing to work on that if 
> you
> are interested. We had talked about this a few times but didn¹t have
> concrete examples beyond some of the things each of us had done
> individually.
> 
> 
> Cheers,
> Morteza
> 
> On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>  wrote:
> 
>> 
>> SCIM gurus,
>> 
>> We decided to define a new resource type named "FidoDevice".
>> 
>> If you're curious about the design:
>> https://github.com/GluuFederation/oxAuth/issues/226
>> 
>> - Mike
>> 
>>  -------------------------------------
>> Michael Schwartz
>> Gluu
>> http://gluu.org
>> 
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim


From nobody Sat Aug 20 09:36:57 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07EE12D56F for ; Sat, 20 Aug 2016 09:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CuEVI1nG1SoT for ; Sat, 20 Aug 2016 09:36:52 -0700 (PDT)
Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B2512B02F for ; Sat, 20 Aug 2016 09:36:52 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) id <0OC700100TEDUJ00@smtpauth4.wiscmail.wisc.edu> for scim@ietf.org; Sat, 20 Aug 2016 11:36:51 -0500 (CDT)
X-Spam-PmxInfo: Server=avs-4, Version=6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.8.20.163015, SenderIP=216.32.180.54
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0054.outbound.protection.outlook.com [216.32.180.54]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPS id <0OC70025RVHDBC50@smtpauth4.wiscmail.wisc.edu>; Sat, 20 Aug 2016 11:36:50 -0500 (CDT)
Received: from CY1PR0601MB1927.namprd06.prod.outlook.com (10.164.221.9) by CY1PR0601MB1925.namprd06.prod.outlook.com (10.164.221.7) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Sat, 20 Aug 2016 16:36:47 +0000
Received: from CY1PR0601MB1927.namprd06.prod.outlook.com ([10.164.221.9]) by CY1PR0601MB1927.namprd06.prod.outlook.com ([10.164.221.9]) with mapi id 15.01.0557.027; Sat, 20 Aug 2016 16:36:47 +0000
From: Keith Hazelton 
To: Mike Schwartz , "Morteza Ansari (moransar)" 
Thread-topic: [scim] FIDO Cred Mgt via SCIM
Thread-index: AQHR+PceZ558sSZVhUCF+xryYgXfFKBQ1yqAgAEvTwD//7XdgA==
Date: Sat, 20 Aug 2016 16:36:47 +0000
Message-id: <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
References:   
In-reply-to: 
Accept-Language: en-US
Content-language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-results: spf=none (sender IP is ) smtp.mailfrom=keith.hazelton@wisc.edu;
x-ms-exchange-messagesentrepresentingtype: 1
X-Originating-IP: [68.190.167.202]
x-ms-office365-filtering-correlation-id: 55f9d25b-6d72-4314-afd9-08d3c9182e0a
x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1925; 6:HaTAnGQpgp8mOMCObAxFqVmGC+cLW0+Izw3auvI/CSuJ6M7tX+rvlrQRuqlglob0yaZ42xzf+u2jb9Twn9Pqk0YfCRA239r3irDaxb4qdEdexSwJdRTi79b2QOAo/sjrbk7iMySDegSmC/cSeLX64Wen+X4jnfVBQAcv0tft/RUexEqQ2jj4rtj1o/RJP4SUAZzElPwFT522QAwW0miYATOwDwx2zLVrNVcRqeWOT9UMgVLmcGA2MNdPg16H/LNeX2s18yn1+/haGZq5JLFD1FtrqL2+a8LY7ZKfuu4KM/FH9YroExpXc+PjtT1Fdp8GWwHKdSyxAMd/cqBM/h4wIQ==; 5:k7PzrJNvS67311nqtDy4KfzuN9214gwCwxpUqZnNWzAud/pG9xK6C//4lYAHsDEaWjUe4phHyh+XRKIqwat0+OQkL0gKhi2jOYhoRkj92sDPmOJVRBeR0t0wmzw2iqR1Be7CWLGZLUY9oPbkQjWH0Q==; 24:c3Os2OU2v1z8Y03VC8AmQvS+XmEKXoaagH4JG/+ww7OKLUfnyx/JP7dyyipjyd3wqZ/uuKDpFzH8PP5ISf7jTggMhlTVnztVOPyAqk2XoqY=; 7:v1lSJV3xZEZdYWX6QzGwP/yqxeDU0D6TalmULAtdgNZZCaRcQqrzZGKQIP4MJdJLVRq4ou1G3Dz/kGcMASW42FHGyu7SG7XspcxEoaXyCuUUYbog5/MeS9w0aAFeJyNVGiyzhDMujbRDjk6exPiiGEVAqTgzt7Jx+3wqgOcfuIFPGmphpggx6sa6/t8ugBwdTYysV2TTohhdKIIOPZU8WRi6GwgtDkBxfrWlLKbx6fDJsxKivUcKGtJCFYoCwDCU
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1925;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(64808622294521)(106557492878310)(166708455590820); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0601MB1925; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1925; 
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377454003)(377424004)(189002)(24454002)(51914003)(105586002)(75432002)(8936002)(92566002)(99286002)(8676002)(81166006)(36756003)(7736002)(81156014)(189998001)(5002640100001)(122556002)(106116001)(305945005)(7846002)(19580395003)(97736004)(5660300001)(33656002)(2900100001)(10400500002)(2950100001)(19580405001)(4326007)(11100500001)(16601075003)(90282001)(106356001)(88552002)(15975445007)(5001770100001)(76176999)(102836003)(2906002)(86362001)(68736007)(586003)(66066001)(77096005)(83716003)(3660700001)(87936001)(101416001)(3846002)(50986999)(3280700002)(1720100001)(82746002)(89122001)(54356999)(6116002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1925; H:CY1PR0601MB1927.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-id: <1F2F05339352714F909207F1AC5FAB32@namprd06.prod.outlook.com>
Content-transfer-encoding: base64
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2016 16:36:47.6080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1925
Archived-At: 
Cc: "scim@ietf.org" 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 16:36:55 -0000

QWxsLA0KDQpJZiBJ4oCZbSBjb3JyZWN0LCBTQ0lNIGhhc27igJl0IHlldCBkZWZpbmVkIGEgRGV2
aWNlIHJlc291cmNlIG9yIHNjaGVtYS4gIFRoYXQgd291bGQgbWVhbiB3ZSBjb3VsZCBwcm9jZWVk
IGluIHR3byBzdGVwczogRGVmaW5lIGFuZCByZWdpc3RlciBhIFNDSU0gRGV2aWNlIHNjaGVtYSB0
aGF0IGNhcnJpZXMgYXR0cmlidXRlcyBjb21tb24gdG8gYWxsIGRldmljZXMsIGFuZCB0aGVuIDIp
IERlZmluZSBhbmQgcmVnaXN0ZXIgYSBTQ0lNIHJlc291cmNlIHR5cGUgYW5kIGV4dGVuc2lvbiBz
Y2hlbWEgZm9yIEZJRE8gZGV2aWNlcyB0aGF0IGFkZCBhbGwgdGhlIEZJRE8tc3BlY2lmaWMgYXR0
cmlidXRlcy4NCg0KICAgICAgICAtLUtlaXRoDQoNCmVtYWlsICYgamFiYmVyOiBrZWl0aC5oYXpl
bHRvbkB3aXNjLmVkdQ0KY2FsZW5kYXI6IGh0dHA6Ly9nby53aXNjLmVkdS9pNnp4eDANCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPbiAyMDE2LTA4LTIwLCAxMTowMiAsICJzY2lt
IG9uIGJlaGFsZiBvZiBNaWtlIFNjaHdhcnR6IiA8c2NpbS1ib3VuY2VzQGlldGYub3JnIG9uIGJl
aGFsZiBvZiBtaWtlQGdsdXUub3JnPiB3cm90ZToNCg0KICAgIE1vcnRlemEsDQogICAgDQogICAg
VGhhbmtzIGZvciB0aGUgb2ZmZXIuIFdlJ2QgZGVmaW5pdGVseSBhcHByZWNpYXRlIGFueSBoZWxw
IG9yIGZlZWRiYWNrLg0KICAgIA0KICAgIEkgd2FzIHdvbmRlcmluZyBhYm91dCBEZXZpY2UuIEkg
d2FzIGNvbmNlcm5lZCB0aGF0IG15IGlkZWEgZm9yIGEgZGV2aWNlIA0KICAgIHdhcyBzb21ldGhp
bmcgbGlrZSBhIHNtYXJ0IHBob25lLCBhbmQgRklETyBkZXZpY2VzIGFyZSBtb3JlIGxpbWl0ZWQu
IFdlIA0KICAgIGVuZGVkIHVwIGRlY2lkaW5nIHRvIGRlZmluZSBhIG5ldyByZXNvdXJjZSB0eXBl
IGNhbGxlZCAiRmlkb0RldmljZSINCiAgICANCiAgICBNb3JlIGRldGFpbHMgb2YgdGhlIGRlc2ln
biBhbmQgcmVxdWlyZW1lbnRzIHdlcmUgZG9jdW1lbnRlZCBvbiB0aGlzIA0KICAgIGdpdGh1YiBp
c3N1ZToNCiAgICAgICBodHRwczovL2dpdGh1Yi5jb20vR2x1dUZlZGVyYXRpb24vb3hBdXRoL2lz
c3Vlcy8yMjYNCiAgICANCiAgICBXZSB3YW50IHRoaXMgdG8gc3VwcG9ydCB0aGUgVTJGLCBVQUYg
YW5kIEZJRE8yIGRldmljZXMgb2YgYSBwZXJzb24uDQogICAgDQogICAgLSBNaWtlDQogICAgDQog
ICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIE1pY2hh
ZWwgU2Nod2FydHoNCiAgICBHbHV1DQogICAgRm91bmRlciAvIENFTw0KICAgIG1pa2VAZ2x1dS5v
cmcNCiAgICANCiAgICBPbiAyMDE2LTA4LTE5IDE2OjU2LCBNb3J0ZXphIEFuc2FyaSAobW9yYW5z
YXIpIHdyb3RlOg0KICAgID4gSGkgTWlrZSwNCiAgICA+IA0KICAgID4gSGF2ZSB5b3UgY29uc2lk
ZXJlZCBkb2luZyBhIGRldmljZSBvYmplY3QgYW5kIGFuIGV4dGVuc2lvbiBmb3IgRmlkbyANCiAg
ICA+IGJpdHM/DQogICAgPiBJIHRoaW5rIGRldmljZSBpcyBhIGdlbmVyaWMgb2JqZWN0IHRoYXQg
d291bGQgYmUgaGVscGZ1bCB0byBkZWZpbmUgYW5kDQogICAgPiBleHRlbmQgaW4gYSByZWFzb25h
Ymx5IGNvbW1vbiB3YXlzLiAgSSBhbSB3aWxsaW5nIHRvIHdvcmsgb24gdGhhdCBpZiANCiAgICA+
IHlvdQ0KICAgID4gYXJlIGludGVyZXN0ZWQuIFdlIGhhZCB0YWxrZWQgYWJvdXQgdGhpcyBhIGZl
dyB0aW1lcyBidXQgZGlkbsK5dCBoYXZlDQogICAgPiBjb25jcmV0ZSBleGFtcGxlcyBiZXlvbmQg
c29tZSBvZiB0aGUgdGhpbmdzIGVhY2ggb2YgdXMgaGFkIGRvbmUNCiAgICA+IGluZGl2aWR1YWxs
eS4NCiAgICA+IA0KICAgID4gDQogICAgPiBDaGVlcnMsDQogICAgPiBNb3J0ZXphDQogICAgPiAN
CiAgICA+IE9uIDgvMTcvMTYsIDc6MjAgUE0sICJzY2ltIG9uIGJlaGFsZiBvZiBNaWtlIFNjaHdh
cnR6Ig0KICAgID4gPHNjaW0tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWlrZUBnbHV1
Lm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+PiANCiAgICA+PiBTQ0lNIGd1cnVzLA0KICAgID4+
IA0KICAgID4+IFdlIGRlY2lkZWQgdG8gZGVmaW5lIGEgbmV3IHJlc291cmNlIHR5cGUgbmFtZWQg
IkZpZG9EZXZpY2UiLg0KICAgID4+IA0KICAgID4+IElmIHlvdSdyZSBjdXJpb3VzIGFib3V0IHRo
ZSBkZXNpZ246DQogICAgPj4gaHR0cHM6Ly9naXRodWIuY29tL0dsdXVGZWRlcmF0aW9uL294QXV0
aC9pc3N1ZXMvMjI2DQogICAgPj4gDQogICAgPj4gLSBNaWtlDQogICAgPj4gDQogICAgPj4gIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+PiBNaWNoYWVsIFNjaHdh
cnR6DQogICAgPj4gR2x1dQ0KICAgID4+IGh0dHA6Ly9nbHV1Lm9yZw0KICAgID4+IA0KICAgID4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4g
c2NpbSBtYWlsaW5nIGxpc3QNCiAgICA+PiBzY2ltQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQogICAgDQogICAgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzY2ltIG1haWxpbmcgbGlz
dA0KICAgIHNjaW1AaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3NjaW0NCiAgICANCg0K


From nobody Sat Aug 20 09:55:02 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1762712B05B for ; Sat, 20 Aug 2016 09:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uATRL8APKUQX for ; Sat, 20 Aug 2016 09:54:58 -0700 (PDT)
Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843E212B020 for ; Sat, 20 Aug 2016 09:54:58 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) id <0OC700C00WB4X000@smtpauth2.wiscmail.wisc.edu> for scim@ietf.org; Sat, 20 Aug 2016 11:54:57 -0500 (CDT)
X-Spam-PmxInfo: Server=avs-2, Version=6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.8.20.164515, SenderIP=216.32.181.24
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0024.outbound.protection.outlook.com [216.32.181.24]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPS id <0OC700JLRWBKXI40@smtpauth2.wiscmail.wisc.edu>; Sat, 20 Aug 2016 11:54:57 -0500 (CDT)
Received: from CY1PR0601MB1927.namprd06.prod.outlook.com (10.164.221.9) by CY1PR0601MB1925.namprd06.prod.outlook.com (10.164.221.7) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Sat, 20 Aug 2016 16:54:54 +0000
Received: from CY1PR0601MB1927.namprd06.prod.outlook.com ([10.164.221.9]) by CY1PR0601MB1927.namprd06.prod.outlook.com ([10.164.221.9]) with mapi id 15.01.0557.027; Sat, 20 Aug 2016 16:54:54 +0000
From: Keith Hazelton 
To: Mike Schwartz , "Morteza Ansari (moransar)" 
Thread-topic: [scim] FIDO Cred Mgt via SCIM
Thread-index: AQHR+PceZ558sSZVhUCF+xryYgXfFKBQ1yqAgAEvTwD//7XdgIAABRAA
Date: Sat, 20 Aug 2016 16:54:54 +0000
Message-id: <95AB2F15-09D4-42F2-9BD9-81E0FF9106C8@wisc.edu>
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
In-reply-to: <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
Accept-Language: en-US
Content-language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-results: spf=none (sender IP is ) smtp.mailfrom=keith.hazelton@wisc.edu;
x-ms-exchange-messagesentrepresentingtype: 1
X-Originating-IP: [68.190.167.202]
x-ms-office365-filtering-correlation-id: 21c2fd61-57e9-46a6-2e68-08d3c91ab5e4
x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1925; 6:MwbiJeCOkqnZS/M5/pM2qPeW62vVw9IbuI1+zH62lBIf0WAXxlQyktGe7hMvCCzH6x6M6zyYSgQjfZuIkb5j9NJq18YOmKIizadIcC6WI1RkS/9V0MIz9Wl0MhOZG0e5Xe9qQL3V+vw6KfGxlp8ndsEwyCsORCFYWg/uWH4ED42GNGDYSxIkvs6TZDph6TNA8Ne+1hlqc2dh2eFdTUOUGHKN3O6UYwFHfDMK6ruNsJaiCj1vfabrbLMKFTY69fa9mhgIBP1AgM+A3tMIfa0AsJXUs6qfB5CGCF7XEqKfEMdyEMAJcbCV/pYmSUbqyyOGyPUi7UU/FYUnjHONW4exUA==; 5:dPLdIsKpSPaAI/Ne5nFMyHVbwrxd/uPuKRuC52LagFS6WRSZa282eBfntX7Qj7HpeKl5O3sY44tdJp9gSGegLiWysfTz32p6iHnaqTo7YOdBtGdDiW8MkfZ2KckM9rxMfhF6mwN+ew5SMKgqdMSIQA==; 24:t5/L1OMv/nL5eToJ/Bx+QNLPNM9C/4W01ghRBbq03BVEBns0HQ/b7kcIpwCx3gc87RUm8QJs6C97Jwr2ryhhQIGMcanIW9X1hYKTMEr42vo=; 7:RYvnW9GF7mgT0PopGSHldR18ze1fM7FEROfIrK7TnOxSBzzLTtbnoPnI+f2SLPib6KFlOByaftsTZexrOw4Utahysipvw5mIsocVQPWZrhp9xU2nJvpaLEVd+mJgvm4P1pDUVGgpUi7LdzRoEvX/LDzitaP1cXynmRMq5PsIwV3p5JII5ml3frKw7Rxg19454x1s4xOo+kptsV9wDCRi8tqArTLu6DQDGwzWFtxXcC+CXXIihzVf6BDdGUxQyG3M
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1925;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(64808622294521)(106557492878310)(166708455590820); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0601MB1925; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1925; 
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(24454002)(51914003)(199003)(377454003)(106356001)(88552002)(90282001)(11100500001)(16601075003)(76176999)(5001770100001)(15975445007)(10400500002)(33656002)(2900100001)(19580405001)(4326007)(2950100001)(87936001)(101416001)(3280700002)(3846002)(50986999)(1720100001)(89122001)(54356999)(6116002)(82746002)(586003)(66066001)(68736007)(102836003)(2906002)(86362001)(77096005)(83716003)(3660700001)(92566002)(99286002)(8676002)(8936002)(105586002)(75432002)(93886004)(305945005)(5660300001)(19580395003)(7846002)(97736004)(81156014)(36756003)(7736002)(189998001)(5002640100001)(81166006)(122556002)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1925; H:CY1PR0601MB1927.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-id: 
Content-transfer-encoding: base64
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2016 16:54:54.4542 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1925
Archived-At: 
Cc: "scim@ietf.org" 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 16:55:00 -0000

QWxsLA0KDQpCam9ybiBBYW5uZXN0YWQgYW5kIE1vcnRlemEgQW5zYXJpIGRpZCBwcmVzZW50IHRv
IElFVEYgOTIgYWJvdXQgYSBwcm9wb3NlZCBTQ0lNIGRldmljZSB0eXBlOiBodHRwczovL3d3dy5p
ZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXNjaW0tMi5wZGYgIEl0IGRv
ZXNu4oCZdCBsb29rIGxpa2UgdGhhdCBoYXMgYmVlbiBmb3JtYWxseSByZWdpc3RlcmVkIHdpdGgg
SUFOQSB5ZXQuDQoNCiAgICAgICAgLS1LZWl0aA0KDQplbWFpbCAmIGphYmJlcjoga2VpdGguaGF6
ZWx0b25Ad2lzYy5lZHUNCmNhbGVuZGFyOiBodHRwOi8vZ28ud2lzYy5lZHUvaTZ6eHgwDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPbiAyMDE2LTA4LTIwLCAxMTozNiAsICJzY2lt
IG9uIGJlaGFsZiBvZiBLZWl0aCBIYXplbHRvbiIgPHNjaW0tYm91bmNlc0BpZXRmLm9yZyBvbiBi
ZWhhbGYgb2Yga2VpdGguaGF6ZWx0b25Ad2lzYy5lZHU+IHdyb3RlOg0KDQogICAgQWxsLA0KICAg
IA0KICAgIElmIEnigJltIGNvcnJlY3QsIFNDSU0gaGFzbuKAmXQgeWV0IGRlZmluZWQgYSBEZXZp
Y2UgcmVzb3VyY2Ugb3Igc2NoZW1hLiAgVGhhdCB3b3VsZCBtZWFuIHdlIGNvdWxkIHByb2NlZWQg
aW4gdHdvIHN0ZXBzOiBEZWZpbmUgYW5kIHJlZ2lzdGVyIGEgU0NJTSBEZXZpY2Ugc2NoZW1hIHRo
YXQgY2FycmllcyBhdHRyaWJ1dGVzIGNvbW1vbiB0byBhbGwgZGV2aWNlcywgYW5kIHRoZW4gMikg
RGVmaW5lIGFuZCByZWdpc3RlciBhIFNDSU0gcmVzb3VyY2UgdHlwZSBhbmQgZXh0ZW5zaW9uIHNj
aGVtYSBmb3IgRklETyBkZXZpY2VzIHRoYXQgYWRkIGFsbCB0aGUgRklETy1zcGVjaWZpYyBhdHRy
aWJ1dGVzLg0KICAgIA0KICAgICAgICAgICAgLS1LZWl0aA0KICAgIA0KICAgIGVtYWlsICYgamFi
YmVyOiBrZWl0aC5oYXplbHRvbkB3aXNjLmVkdQ0KICAgIGNhbGVuZGFyOiBodHRwOi8vZ28ud2lz
Yy5lZHUvaTZ6eHgwDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBP
biAyMDE2LTA4LTIwLCAxMTowMiAsICJzY2ltIG9uIGJlaGFsZiBvZiBNaWtlIFNjaHdhcnR6IiA8
c2NpbS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtaWtlQGdsdXUub3JnPiB3cm90ZToN
CiAgICANCiAgICAgICAgTW9ydGV6YSwNCiAgICAgICAgDQogICAgICAgIFRoYW5rcyBmb3IgdGhl
IG9mZmVyLiBXZSdkIGRlZmluaXRlbHkgYXBwcmVjaWF0ZSBhbnkgaGVscCBvciBmZWVkYmFjay4N
CiAgICAgICAgDQogICAgICAgIEkgd2FzIHdvbmRlcmluZyBhYm91dCBEZXZpY2UuIEkgd2FzIGNv
bmNlcm5lZCB0aGF0IG15IGlkZWEgZm9yIGEgZGV2aWNlIA0KICAgICAgICB3YXMgc29tZXRoaW5n
IGxpa2UgYSBzbWFydCBwaG9uZSwgYW5kIEZJRE8gZGV2aWNlcyBhcmUgbW9yZSBsaW1pdGVkLiBX
ZSANCiAgICAgICAgZW5kZWQgdXAgZGVjaWRpbmcgdG8gZGVmaW5lIGEgbmV3IHJlc291cmNlIHR5
cGUgY2FsbGVkICJGaWRvRGV2aWNlIg0KICAgICAgICANCiAgICAgICAgTW9yZSBkZXRhaWxzIG9m
IHRoZSBkZXNpZ24gYW5kIHJlcXVpcmVtZW50cyB3ZXJlIGRvY3VtZW50ZWQgb24gdGhpcyANCiAg
ICAgICAgZ2l0aHViIGlzc3VlOg0KICAgICAgICAgICBodHRwczovL2dpdGh1Yi5jb20vR2x1dUZl
ZGVyYXRpb24vb3hBdXRoL2lzc3Vlcy8yMjYNCiAgICAgICAgDQogICAgICAgIFdlIHdhbnQgdGhp
cyB0byBzdXBwb3J0IHRoZSBVMkYsIFVBRiBhbmQgRklETzIgZGV2aWNlcyBvZiBhIHBlcnNvbi4N
CiAgICAgICAgDQogICAgICAgIC0gTWlrZQ0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgTWljaGFlbCBTY2h3
YXJ0eg0KICAgICAgICBHbHV1DQogICAgICAgIEZvdW5kZXIgLyBDRU8NCiAgICAgICAgbWlrZUBn
bHV1Lm9yZw0KICAgICAgICANCiAgICAgICAgT24gMjAxNi0wOC0xOSAxNjo1NiwgTW9ydGV6YSBB
bnNhcmkgKG1vcmFuc2FyKSB3cm90ZToNCiAgICAgICAgPiBIaSBNaWtlLA0KICAgICAgICA+IA0K
ICAgICAgICA+IEhhdmUgeW91IGNvbnNpZGVyZWQgZG9pbmcgYSBkZXZpY2Ugb2JqZWN0IGFuZCBh
biBleHRlbnNpb24gZm9yIEZpZG8gDQogICAgICAgID4gYml0cz8NCiAgICAgICAgPiBJIHRoaW5r
IGRldmljZSBpcyBhIGdlbmVyaWMgb2JqZWN0IHRoYXQgd291bGQgYmUgaGVscGZ1bCB0byBkZWZp
bmUgYW5kDQogICAgICAgID4gZXh0ZW5kIGluIGEgcmVhc29uYWJseSBjb21tb24gd2F5cy4gIEkg
YW0gd2lsbGluZyB0byB3b3JrIG9uIHRoYXQgaWYgDQogICAgICAgID4geW91DQogICAgICAgID4g
YXJlIGludGVyZXN0ZWQuIFdlIGhhZCB0YWxrZWQgYWJvdXQgdGhpcyBhIGZldyB0aW1lcyBidXQg
ZGlkbsK5dCBoYXZlDQogICAgICAgID4gY29uY3JldGUgZXhhbXBsZXMgYmV5b25kIHNvbWUgb2Yg
dGhlIHRoaW5ncyBlYWNoIG9mIHVzIGhhZCBkb25lDQogICAgICAgID4gaW5kaXZpZHVhbGx5Lg0K
ICAgICAgICA+IA0KICAgICAgICA+IA0KICAgICAgICA+IENoZWVycywNCiAgICAgICAgPiBNb3J0
ZXphDQogICAgICAgID4gDQogICAgICAgID4gT24gOC8xNy8xNiwgNzoyMCBQTSwgInNjaW0gb24g
YmVoYWxmIG9mIE1pa2UgU2Nod2FydHoiDQogICAgICAgID4gPHNjaW0tYm91bmNlc0BpZXRmLm9y
ZyBvbiBiZWhhbGYgb2YgbWlrZUBnbHV1Lm9yZz4gd3JvdGU6DQogICAgICAgID4gDQogICAgICAg
ID4+IA0KICAgICAgICA+PiBTQ0lNIGd1cnVzLA0KICAgICAgICA+PiANCiAgICAgICAgPj4gV2Ug
ZGVjaWRlZCB0byBkZWZpbmUgYSBuZXcgcmVzb3VyY2UgdHlwZSBuYW1lZCAiRmlkb0RldmljZSIu
DQogICAgICAgID4+IA0KICAgICAgICA+PiBJZiB5b3UncmUgY3VyaW91cyBhYm91dCB0aGUgZGVz
aWduOg0KICAgICAgICA+PiBodHRwczovL2dpdGh1Yi5jb20vR2x1dUZlZGVyYXRpb24vb3hBdXRo
L2lzc3Vlcy8yMjYNCiAgICAgICAgPj4gDQogICAgICAgID4+IC0gTWlrZQ0KICAgICAgICA+PiAN
CiAgICAgICAgPj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg
ICAgPj4gTWljaGFlbCBTY2h3YXJ0eg0KICAgICAgICA+PiBHbHV1DQogICAgICAgID4+IGh0dHA6
Ly9nbHV1Lm9yZw0KICAgICAgICA+PiANCiAgICAgICAgPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgPj4gc2NpbSBtYWlsaW5nIGxpc3QN
CiAgICAgICAgPj4gc2NpbUBpZXRmLm9yZw0KICAgICAgICA+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCiAgICAgICAgDQogICAgICAgIF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIHNjaW0gbWFpbGluZyBs
aXN0DQogICAgICAgIHNjaW1AaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zY2ltDQogICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2NpbSBtYWlsaW5nIGxpc3QN
CiAgICBzY2ltQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9zY2ltDQogICAgDQoNCg==


From nobody Sat Aug 20 10:00:35 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01E412B015 for ; Sat, 20 Aug 2016 10:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.85
X-Spam-Level: 
X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YaN2t2IPp0GV for ; Sat, 20 Aug 2016 10:00:33 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 86A0012B00F for ; Sat, 20 Aug 2016 10:00:33 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7KH0UD6006877 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Aug 2016 17:00:31 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7KH0UNr022494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Aug 2016 17:00:30 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u7KH0Tf4032187; Sat, 20 Aug 2016 17:00:29 GMT
Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Aug 2016 10:00:29 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
Date: Sat, 20 Aug 2016 10:00:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DEFC0E5-B9CD-48D2-8145-F13CD5DD7D33@oracle.com>
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
To: Keith Hazelton 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: Mike Schwartz , "scim@ietf.org" , "Morteza Ansari \(moransar\)" 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 17:00:35 -0000

I think this could be something the scim WG could address.=20

Mike would you be willing to submit your draft to the ietf so that it may be=
 considered?

Phil

> On Aug 20, 2016, at 9:36 AM, Keith Hazelton  wrot=
e:
>=20
> All,
>=20
> If I=E2=80=99m correct, SCIM hasn=E2=80=99t yet defined a Device resource o=
r schema.  That would mean we could proceed in two steps: Define and registe=
r a SCIM Device schema that carries attributes common to all devices, and th=
en 2) Define and register a SCIM resource type and extension schema for FIDO=
 devices that add all the FIDO-specific attributes.
>=20
>        --Keith
>=20
> email & jabber: keith.hazelton@wisc.edu
> calendar: http://go.wisc.edu/i6zxx0
> ________________________________
> On 2016-08-20, 11:02 , "scim on behalf of Mike Schwartz"  wrote:
>=20
>    Morteza,
>=20
>    Thanks for the offer. We'd definitely appreciate any help or feedback.
>=20
>    I was wondering about Device. I was concerned that my idea for a device=
=20
>    was something like a smart phone, and FIDO devices are more limited. We=
=20
>    ended up deciding to define a new resource type called "FidoDevice"
>=20
>    More details of the design and requirements were documented on this=20
>    github issue:
>       https://github.com/GluuFederation/oxAuth/issues/226
>=20
>    We want this to support the U2F, UAF and FIDO2 devices of a person.
>=20
>    - Mike
>=20
>=20
>    -------------------------------------
>    Michael Schwartz
>    Gluu
>    Founder / CEO
>    mike@gluu.org
>=20
>>    On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
>> Hi Mike,
>>=20
>> Have you considered doing a device object and an extension for Fido=20
>> bits?
>> I think device is a generic object that would be helpful to define and
>> extend in a reasonably common ways.  I am willing to work on that if=20
>> you
>> are interested. We had talked about this a few times but didn=C2=B9t have=

>> concrete examples beyond some of the things each of us had done
>> individually.
>>=20
>>=20
>> Cheers,
>> Morteza
>>=20
>> On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>>  wrote:
>>=20
>>>=20
>>> SCIM gurus,
>>>=20
>>> We decided to define a new resource type named "FidoDevice".
>>>=20
>>> If you're curious about the design:
>>> https://github.com/GluuFederation/oxAuth/issues/226
>>>=20
>>> - Mike
>>>=20
>>> -------------------------------------
>>> Michael Schwartz
>>> Gluu
>>> http://gluu.org
>>>=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
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From nobody Sat Aug 20 12:06:45 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE6312D19B for ; Sat, 20 Aug 2016 12:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.438
X-Spam-Level: 
X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 dmd5emiRXydw for ; Sat, 20 Aug 2016 12:06:42 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE3F12D190 for ; Sat, 20 Aug 2016 12:06:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id EA71CB41BD for ; Sat, 20 Aug 2016 19:06:41 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1471720001; x=1472584002; bh=bFyx8KFTuj ZMR93Q+Rc9KQzs7cAv4rSDl59fcDEpVRo=; b=AYesA1Pl5+6sUAkzl8tquqI9EL ezSZNSdPTUe1Yb9Znwe5+u3nUaRlvKakhKQCTN7mJX6jkw33O9MDT4y2C8oq/cNn zu5vJ95YZAhWymt1vzwu9ZLarlkN4kAW7xCZLPagOcmRWvMo7lN1wuWzAEeivf1N 8g7LYULDcTi1jBwM0=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjg6y7j-WsqC for ; Sat, 20 Aug 2016 19:06:41 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 69F64B41B3; Sat, 20 Aug 2016 19:06:41 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 20 Aug 2016 14:06:41 -0500
From: Mike Schwartz 
To: "Phil Hunt (IDM)" 
Organization: Gluu
In-Reply-To: <4DEFC0E5-B9CD-48D2-8145-F13CD5DD7D33@oracle.com>
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu> <4DEFC0E5-B9CD-48D2-8145-F13CD5DD7D33@oracle.com>
Message-ID: <34443e350db1de02fd8e89b0c62005df@gluu.org>
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" , Keith Hazelton 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 19:06:44 -0000

Yes, if it makes sense, we'd be happy to contribute any of this work.

Right now Gluu is working on U2F / UAF. If we publish this more widely, 
we need make sure we have any new metadata for FIDO 2.

- Mike



-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org

On 2016-08-20 12:00, Phil Hunt (IDM) wrote:
> I think this could be something the scim WG could address.
> 
> Mike would you be willing to submit your draft to the ietf so that it
> may be considered?
> 
> Phil
> 
>> On Aug 20, 2016, at 9:36 AM, Keith Hazelton  
>> wrote:
>> 
>> All,
>> 
>> If I’m correct, SCIM hasn’t yet defined a Device resource or schema.  
>> That would mean we could proceed in two steps: Define and register a 
>> SCIM Device schema that carries attributes common to all devices, and 
>> then 2) Define and register a SCIM resource type and extension schema 
>> for FIDO devices that add all the FIDO-specific attributes.
>> 
>>        --Keith
>> 
>> email & jabber: keith.hazelton@wisc.edu
>> calendar: http://go.wisc.edu/i6zxx0
>> ________________________________
>> On 2016-08-20, 11:02 , "scim on behalf of Mike Schwartz" 
>>  wrote:
>> 
>>    Morteza,
>> 
>>    Thanks for the offer. We'd definitely appreciate any help or 
>> feedback.
>> 
>>    I was wondering about Device. I was concerned that my idea for a 
>> device
>>    was something like a smart phone, and FIDO devices are more 
>> limited. We
>>    ended up deciding to define a new resource type called "FidoDevice"
>> 
>>    More details of the design and requirements were documented on this
>>    github issue:
>>       https://github.com/GluuFederation/oxAuth/issues/226
>> 
>>    We want this to support the U2F, UAF and FIDO2 devices of a person.
>> 
>>    - Mike
>> 
>> 
>>    -------------------------------------
>>    Michael Schwartz
>>    Gluu
>>    Founder / CEO
>>    mike@gluu.org
>> 
>>>    On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
>>> Hi Mike,
>>> 
>>> Have you considered doing a device object and an extension for Fido
>>> bits?
>>> I think device is a generic object that would be helpful to define 
>>> and
>>> extend in a reasonably common ways.  I am willing to work on that if
>>> you
>>> are interested. We had talked about this a few times but didn¹t have
>>> concrete examples beyond some of the things each of us had done
>>> individually.
>>> 
>>> 
>>> Cheers,
>>> Morteza
>>> 
>>> On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>>>  wrote:
>>> 
>>>> 
>>>> SCIM gurus,
>>>> 
>>>> We decided to define a new resource type named "FidoDevice".
>>>> 
>>>> If you're curious about the design:
>>>> https://github.com/GluuFederation/oxAuth/issues/226
>>>> 
>>>> - Mike
>>>> 
>>>> -------------------------------------
>>>> Michael Schwartz
>>>> Gluu
>>>> http://gluu.org
>>>> 
>>>> _______________________________________________
>>>> 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/mailman/listinfo/scim


From nobody Sat Aug 20 12:09:52 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666DB12D19B for ; Sat, 20 Aug 2016 12:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.438
X-Spam-Level: 
X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 Mei1dJ634dJj for ; Sat, 20 Aug 2016 12:09:50 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F37128874 for ; Sat, 20 Aug 2016 12:09:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 1FC0FB41CB for ; Sat, 20 Aug 2016 19:09:49 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1471720188; x=1472584189; bh=j4T4Yo6sTZ hV2KPo9XEsU13IuaDuSIsu2+PvTAJF7yo=; b=iZlm/vkW+DJOfFG22RoXFjNWkB BZIFsEWVwSV8gdB/lnmFwYWJFII0JYfSUx0vh0IB0sJQ38qxAYFcBxQT2S2YLn4R DM/oWgrr8wTvswygGEk2IZM3ixgrE45zOyeV9iEhtSO8n0wDeQoBAn+Sv2e1PhOZ Rf9zOWQ3n/tvOKI1k=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Msj8o7dsLq for ; Sat, 20 Aug 2016 19:09:48 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id B7DC0B41B3; Sat, 20 Aug 2016 19:09:48 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 20 Aug 2016 14:09:48 -0500
From: Mike Schwartz 
To: Keith Hazelton 
Organization: Gluu
In-Reply-To: <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu>
Message-ID: <304f70e47df3ff301e7b8acf6ab03e61@gluu.org>
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 19:09:51 -0000

I don't know if a FIDO credential is really a device. It's a fancy 
password with lots of metadata.

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org

On 2016-08-20 11:36, Keith Hazelton wrote:
> All,
> 
> If I’m correct, SCIM hasn’t yet defined a Device resource or schema.
> That would mean we could proceed in two steps: Define and register a
> SCIM Device schema that carries attributes common to all devices, and
> then 2) Define and register a SCIM resource type and extension schema
> for FIDO devices that add all the FIDO-specific attributes.
> 
>         --Keith
> 
> email & jabber: keith.hazelton@wisc.edu
> calendar: http://go.wisc.edu/i6zxx0
> ________________________________
> On 2016-08-20, 11:02 , "scim on behalf of Mike Schwartz"
>  wrote:
> 
>     Morteza,
> 
>     Thanks for the offer. We'd definitely appreciate any help or 
> feedback.
> 
>     I was wondering about Device. I was concerned that my idea for a 
> device
>     was something like a smart phone, and FIDO devices are more 
> limited. We
>     ended up deciding to define a new resource type called "FidoDevice"
> 
>     More details of the design and requirements were documented on this
>     github issue:
>        https://github.com/GluuFederation/oxAuth/issues/226
> 
>     We want this to support the U2F, UAF and FIDO2 devices of a person.
> 
>     - Mike
> 
> 
>     -------------------------------------
>     Michael Schwartz
>     Gluu
>     Founder / CEO
>     mike@gluu.org
> 
>     On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
>     > Hi Mike,
>     >
>     > Have you considered doing a device object and an extension for 
> Fido
>     > bits?
>     > I think device is a generic object that would be helpful to 
> define and
>     > extend in a reasonably common ways.  I am willing to work on that 
> if
>     > you
>     > are interested. We had talked about this a few times but didn¹t 
> have
>     > concrete examples beyond some of the things each of us had done
>     > individually.
>     >
>     >
>     > Cheers,
>     > Morteza
>     >
>     > On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>     >  wrote:
>     >
>     >>
>     >> SCIM gurus,
>     >>
>     >> We decided to define a new resource type named "FidoDevice".
>     >>
>     >> If you're curious about the design:
>     >> https://github.com/GluuFederation/oxAuth/issues/226
>     >>
>     >> - Mike
>     >>
>     >>  -------------------------------------
>     >> Michael Schwartz
>     >> Gluu
>     >> http://gluu.org
>     >>
>     >> _______________________________________________
>     >> 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


From nobody Sat Aug 20 12:27:05 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE11412B051 for ; Sat, 20 Aug 2016 12:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wi1KPp9m8_qK for ; Sat, 20 Aug 2016 12:27:00 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 42C4C12D1A3 for ; Sat, 20 Aug 2016 12:27:00 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7KJQv9v028570 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Aug 2016 19:26:57 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7KJQumV015212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Aug 2016 19:26:57 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7KJQu3w014810; Sat, 20 Aug 2016 19:26:56 GMT
Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Aug 2016 12:26:55 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_91844D28-1702-48FD-A141-D5F38ED39E4E"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: <304f70e47df3ff301e7b8acf6ab03e61@gluu.org>
Date: Sat, 20 Aug 2016 12:26:53 -0700
Message-Id: 
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu> <304f70e47df3ff301e7b8acf6ab03e61@gluu.org>
To: Mike Schwartz 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: scim@ietf.org, Morteza Ansari , Keith Hazelton 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 19:27:02 -0000

--Apple-Mail=_91844D28-1702-48FD-A141-D5F38ED39E4E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Something to discuss is what should be an extension of User vs. Device =
and what the references are in between.

It may be useful to also track token binding relationships too.

Phil

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






> On Aug 20, 2016, at 12:09 PM, Mike Schwartz  wrote:
>=20
>=20
> I don't know if a FIDO credential is really a device. It's a fancy =
password with lots of metadata.
>=20
> - Mike
>=20
>=20
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> mike@gluu.org
>=20
> On 2016-08-20 11:36, Keith Hazelton wrote:
>> All,
>> If I=E2=80=99m correct, SCIM hasn=E2=80=99t yet defined a Device =
resource or schema.
>> That would mean we could proceed in two steps: Define and register a
>> SCIM Device schema that carries attributes common to all devices, and
>> then 2) Define and register a SCIM resource type and extension schema
>> for FIDO devices that add all the FIDO-specific attributes.
>>        --Keith
>> email & jabber: keith.hazelton@wisc.edu
>> calendar: http://go.wisc.edu/i6zxx0
>> ________________________________
>> On 2016-08-20, 11:02 , "scim on behalf of Mike Schwartz"
>>  wrote:
>>    Morteza,
>>    Thanks for the offer. We'd definitely appreciate any help or =
feedback.
>>    I was wondering about Device. I was concerned that my idea for a =
device
>>    was something like a smart phone, and FIDO devices are more =
limited. We
>>    ended up deciding to define a new resource type called =
"FidoDevice"
>>    More details of the design and requirements were documented on =
this
>>    github issue:
>>       https://github.com/GluuFederation/oxAuth/issues/226
>>    We want this to support the U2F, UAF and FIDO2 devices of a =
person.
>>    - Mike
>>    -------------------------------------
>>    Michael Schwartz
>>    Gluu
>>    Founder / CEO
>>    mike@gluu.org
>>    On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
>>    > Hi Mike,
>>    >
>>    > Have you considered doing a device object and an extension for =
Fido
>>    > bits?
>>    > I think device is a generic object that would be helpful to =
define and
>>    > extend in a reasonably common ways.  I am willing to work on =
that if
>>    > you
>>    > are interested. We had talked about this a few times but didn=C2=B9=
t have
>>    > concrete examples beyond some of the things each of us had done
>>    > individually.
>>    >
>>    >
>>    > Cheers,
>>    > Morteza
>>    >
>>    > On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>>    >  wrote:
>>    >
>>    >>
>>    >> SCIM gurus,
>>    >>
>>    >> We decided to define a new resource type named "FidoDevice".
>>    >>
>>    >> If you're curious about the design:
>>    >> https://github.com/GluuFederation/oxAuth/issues/226
>>    >>
>>    >> - Mike
>>    >>
>>    >>  -------------------------------------
>>    >> Michael Schwartz
>>    >> Gluu
>>    >> http://gluu.org
>>    >>
>>    >> _______________________________________________
>>    >> 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
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_91844D28-1702-48FD-A141-D5F38ED39E4E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Something to discuss is what should be an extension of User =
vs. Device and what the references are in between.

It may be useful to also track token =
binding relationships too.








On Aug 20, 2016, at 12:09 PM, Mike Schwartz <mike@gluu.org> =
wrote:


I don't know if a FIDO credential is really a =
device. It's a fancy password with lots of metadata.

- Mike


-------------------------------------
Michael =
Schwartz
Gluu
Founder / CEO
mike@gluu.org

On 2016-08-20 11:36, Keith Hazelton wrote:
All,
If =
I=E2=80=99m correct, SCIM hasn=E2=80=99t yet defined a Device resource =
or schema.
That would mean we could proceed in two steps: =
Define and register a
SCIM Device schema that carries =
attributes common to all devices, and
then 2) Define and =
register a SCIM resource type and extension schema
for =
FIDO devices that add all the FIDO-specific attributes.
 =
       --Keith
email =
& jabber: keith.hazelton@wisc.edu
calendar: =
http://go.wisc.edu/i6zxx0
________________________________
On 2016-08-20, =
11:02 , "scim on behalf of Mike Schwartz"
<scim-bounces@ietf.org on behalf of mike@gluu.org> =
wrote:
    Morteza,
 =
   Thanks for the offer. We'd definitely appreciate any =
help or feedback.
    I was wondering about =
Device. I was concerned that my idea for a device
 =
   was something like a smart phone, and FIDO devices are =
more limited. We
    ended up deciding to =
define a new resource type called "FidoDevice"
 =
   More details of the design and requirements were =
documented on this
    github issue:
 =
      https://github.com/GluuFederation/oxAu=
th/issues/226
    We want this to support =
the U2F, UAF and FIDO2 devices of a person.
 =
   - Mike
 =
   -------------------------------------
 =
   Michael Schwartz
 =
   Gluu
    Founder / CEO
    mike@gluu.org
 =
   On 2016-08-19 16:56, Morteza Ansari (moransar) =
wrote:
    > Hi Mike,
 =
   >
    > Have you =
considered doing a device object and an extension for Fido
 =
   > bits?
    > I =
think device is a generic object that would be helpful to define and
    > extend in a reasonably common ways. =
 I am willing to work on that if
 =
   > you
    > are =
interested. We had talked about this a few times but didn=C2=B9t have
    > concrete examples beyond some of the =
things each of us had done
    > =
individually.
    >
 =
   >
    > Cheers,
    > Morteza
 =
   >
    > On 8/17/16, =
7:20 PM, "scim on behalf of Mike Schwartz"
 =
   > <scim-bounces@ietf.org on behalf of =
mike@gluu.org> wrote:
    >
    >>
 =
   >> SCIM gurus,
 =
   >>
    >> We =
decided to define a new resource type named "FidoDevice".
 =
   >>
    >> If =
you're curious about the design:
 =
   >> =
https://github.com/GluuFederation/oxAuth/issues/226
 =
   >>
    >> - =
Mike
    >>
 =
   >> =
 -------------------------------------
 =
   >> Michael Schwartz
 =
   >> Gluu
 =
   >> http://gluu.org
 =
   >>
    >> =
_______________________________________________
 =
   >> 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/mailman/listinfo/scim

=

--Apple-Mail=_91844D28-1702-48FD-A141-D5F38ED39E4E--


From nobody Sat Aug 20 19:11:36 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8912D0A9 for ; Sat, 20 Aug 2016 19:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.467
X-Spam-Level: 
X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=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 YOZgiep-zM4w for ; Sat, 20 Aug 2016 19:11:32 -0700 (PDT)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id EAEC412B02A for ; Sat, 20 Aug 2016 19:11:31 -0700 (PDT)
Received: (qmail 40028 invoked by uid 99); 21 Aug 2016 02:11:30 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Aug 2016 02:11:30 +0000
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 515751A0118; Sun, 21 Aug 2016 02:11:30 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id l203so110773251oib.1; Sat, 20 Aug 2016 19:11:30 -0700 (PDT)
X-Gm-Message-State: AEkoousHHO0Leu7U/xx8w6G0kPGqFfyxnR8LC7VP/Sc0kswXQhpdboA0GTJpZzQ9sBO6nUaZs5fuS/T74VaRjw==
X-Received: by 10.202.107.213 with SMTP id g204mr8200014oic.64.1471745489678;  Sat, 20 Aug 2016 19:11:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.111.165 with HTTP; Sat, 20 Aug 2016 19:11:28 -0700 (PDT)
In-Reply-To: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com>
References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com> <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com>
From: Kiran Ayyagari 
Date: Sun, 21 Aug 2016 07:41:28 +0530
X-Gmail-Original-Message-ID: 
Message-ID: 
To: id-event@ietf.org, openid-specs-risc@lists.openid.net
Content-Type: multipart/alternative; boundary=001a11408c8e1cbb96053a8b7318
Archived-At: 
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Aug 2016 02:11:34 -0000

--001a11408c8e1cbb96053a8b7318
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is there any specific reason for making "events" attribute an array of
event URIs?

If not, can this be turned into an object containing  pairs?

Thank you.

On Thu, Aug 18, 2016 at 9:40 PM, Phil Hunt  wrote:

> Draft 03 has been published.
>
> This includes editorial clarifications to:
> * Define the outer layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs embedded=
 JSON as =E2=80=9Cpayload=E2=80=9D
> * Clarify that only a single event should be conveyed plus optional
> extensions.
> * General edits to improve readability
> * Register the =E2=80=9Cevents=E2=80=9D claim as a  JWT attribute (see IA=
NA considerations)
>
> Many thanks to Mike and Sarah and who contributed significant editorial
> feedback.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *Subject: **New Version Notification for draft-hunt-idevent-token-03.txt*
> *Date: *August 18, 2016 at 9:03:35 AM PDT
> *To: *"Michael B. Jones" , "William Denniss" <
> wdenniss@google.com>, "Phil Hunt" , "Morteza Ansari"
> , "Michael Jones" 
>
>
> A new version of I-D, draft-hunt-idevent-token-03.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>
> Name: draft-hunt-idevent-token
> Revision: 03
> Title: Security Event Token (SET)
> Document date: 2016-08-18
> Group: Individual Submission
> Pages: 16
> URL:            https://www.ietf.org/internet-drafts/draft-
> hunt-idevent-token-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token=
/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-03
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-
> idevent-token-03
>
> Abstract:
>   This specification defines the Security Event token, which may be
>   distributed via a protocol such as HTTP.  The Security Event Token
>   (SET) specification profiles the JSON Web Token (JWT) and may be
>   optionally signed and/or encrypted.  A SET describes a statement of
>   fact that may be shared by an event publisher with event subscribers.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
> Kiran Ayyagari

--001a11408c8e1cbb96053a8b7318
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Is there any specific reason for making "ev=
ents" attribute an array of event URIs?

If not, can this =
be turned into an object containing <event-uri, event-data> pairs?
Thank you.

On Thu, Aug 18, 2016 at 9:40 PM, Phil Hunt <phil=
.hunt@oracle.com> wrote:
Draft 03 has been published.

This includes editorial clarifications to:
* Define the ou=
ter layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs embedded JSON as =E2=80=
=9Cpayload=E2=80=9D
* Clarify that only a single event should be =
conveyed plus optional extensions.
* General edits to improve rea=
dability
* Register the =E2=80=9Cevents=E2=80=9D claim as a =C2=
=A0JWT attribute (see IANA considerations)

Many th=
anks to Mike and Sarah and who contributed significant editorial feedback.<=
/div>





Begin forwarded message:

<=
div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:=
0px">From: internet-drafts@ietf.or=
g
Subject: =
New Version Notification for draft-hunt-idevent-token-03=
.txt
Date:=
 August 18, 2016 at 9:03:35 AM PDT
To: "Michael B=
. Jones" <mb=
j@microsoft.com>, "William Denniss" <wdenniss@google.com>, "P=
hil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-03.txt
has been su=
ccessfully submitted by Phil Hunt and posted to the
IETF repository.
=

Name:		draft-hunt-idevent-token
Revision:	03
Title:		Security Event To=
ken (SET)
Document date:	201=
6-08-18
Group:		Individual Submission
Pages:		16
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0https://www.ietf.org/internet-drafts/=
draft-hunt-idevent-token-03.txt
Status: =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/=
doc/draft-hunt-idevent-token/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-hunt-ideve=
nt-token-03
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3D=
draft-hunt-idevent-token-03

Abstract:
 =C2=A0=C2=A0This =
specification defines the Security Event token, which may be
 =C2=A0=C2=
=A0distributed via a protocol such as HTTP.=C2=A0 The Security Event Token<=
br> =C2=A0=C2=A0(SET) specification profiles the JSON Web Token (JWT) and m=
ay be
 =C2=A0=C2=A0optionally signed and/or encrypted.=C2=A0 A SET descr=
ibes a statement of
 =C2=A0=C2=A0fact that may be shared by an event pub=
lisher with event subscribers.




Please note that it may t=
ake a couple of minutes from the time of submission
until the htmlized v=
ersion and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________

Id-event mailing list

Id-event@ietf.org

https://www.ietf.org/mailman/listinfo/id-event


Kiran Ayyagari


--001a11408c8e1cbb96053a8b7318--


From nobody Tue Aug 23 08:31:21 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364312DA9F for ; Tue, 23 Aug 2016 08:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Level: 
X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 5jBAIJzQZ3By for ; Tue, 23 Aug 2016 08:31:18 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA8B12D5E3 for ; Tue, 23 Aug 2016 08:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19771; q=dns/txt; s=iport; t=1471965067; x=1473174667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6KruAHny+LMr2Yk5Yn8ML1wvxVif3e4Lu5ERYctLiII=; b=eZqk1gIDvaySz1AJzhWPuAD0BJZcEl90PhaufRm9yWk/yZ3L8D6+FTi5 9r1+zIGr8pbyrON4PgTKTTBxbt0x64yGHHabMKwlRlCueb9O9Vdb9CDWN i9RytK3c5xg6OsQrDHYUpl6YSkaoa8YyZkMj++6Wv1rvnh958e1OvwVXQ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AgA7ZrxX/4sNJK1dgnYzAQEBAQEcV?= =?us-ascii?q?nYGB7J4hQiBfSSFL0oCHIFNOBQCAQEBAQEBAV4nhGABAQQBAQFHHgcEBxACAQg?= =?us-ascii?q?RAwECARgPBQICJQsUCQgCBAENBYgpCAkFkD6dGgaQBQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARyGLYRNhBIKBwEzCR4Qgi2CYAWIK5EdAYYfiQGCO40ViE+DcYN4AQ8?= =?us-ascii?q?PNoN6cIRMDxcgfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,566,1464652800";  d="scan'208,217";a="140837066"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2016 15:11:06 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u7NFB6qs008568 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Aug 2016 15:11:06 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 10:11:05 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 10:11:05 -0500
From: "Morteza Ansari (moransar)" 
To: Phil Hunt , Mike Schwartz 
Thread-Topic: [scim] FIDO Cred Mgt via SCIM
Thread-Index: AQHR+PcfjCdKY88iHk+U7QE1PGsGsaBQtaGAgAGkqgCAAAmugIAAKsEAgAAExoCAA/oGAA==
Date: Tue, 23 Aug 2016 15:11:05 +0000
Message-ID: 
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu> <304f70e47df3ff301e7b8acf6ab03e61@gluu.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.58.242]
Content-Type: multipart/alternative; boundary="_000_D3E1B51644796moransarciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "scim@ietf.org" , Keith Hazelton 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2016 15:31:20 -0000

--_000_D3E1B51644796moransarciscocom_
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64

VG8gYmUgY2xlYXIgSSB3YXMgc3VnZ2VzdGluZyBhIHRvcCBsZXZlbCBlbmRwb2ludCBsaWtlIC9k
ZXZpY2VzIGFuZCBjb3JlIHNjaGVtYSBmb3IgdGhlIGRldmljZSBpdHNlbGYgcGx1cyBleHRlbnNp
b25zIGZvciBGSURPLiBUaGlzIHdheSB3ZSBoYXZlIGEgcGxhY2UgdG8gZXh0ZW5kIHRoZSBkZXZp
Y2UgY2xhc3MgYW5kIGhhbmcgYW55IGFkZGl0aW9uYWwgZGV2aWNlIGV4dGVuc2lvbnMuIERldmlj
ZXMgYXJlIG5vdCBhbGwgRklETyBvciBjZWxsIHBob25lIG9yoaYNCg0KRnJvbTogUGhpbCBIdW50
IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KRGF0
ZTogU2F0dXJkYXksIEF1Z3VzdCAyMCwgMjAxNiBhdCAxMjoyNiBQTQ0KVG86IE1pa2UgU2Nod2Fy
dHogPG1pa2VAZ2x1dS5vcmc8bWFpbHRvOm1pa2VAZ2x1dS5vcmc+Pg0KQ2M6IEtlaXRoIEhhemVs
dG9uIDxrZWl0aC5oYXplbHRvbkB3aXNjLmVkdTxtYWlsdG86a2VpdGguaGF6ZWx0b25Ad2lzYy5l
ZHU+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+IiA8c2NpbUBpZXRmLm9y
ZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+LCBNb3J0ZXphIDxtb3JhbnNhckBjaXNjby5jb208bWFp
bHRvOm1vcmFuc2FyQGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NjaW1dIEZJRE8gQ3JlZCBN
Z3QgdmlhIFNDSU0NCg0KU29tZXRoaW5nIHRvIGRpc2N1c3MgaXMgd2hhdCBzaG91bGQgYmUgYW4g
ZXh0ZW5zaW9uIG9mIFVzZXIgdnMuIERldmljZSBhbmQgd2hhdCB0aGUgcmVmZXJlbmNlcyBhcmUg
aW4gYmV0d2Vlbi4NCg0KSXQgbWF5IGJlIHVzZWZ1bCB0byBhbHNvIHRyYWNrIHRva2VuIGJpbmRp
bmcgcmVsYXRpb25zaGlwcyB0b28uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl
cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9y
YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIEF1ZyAy
MCwgMjAxNiwgYXQgMTI6MDkgUE0sIE1pa2UgU2Nod2FydHogPG1pa2VAZ2x1dS5vcmc8bWFpbHRv
Om1pa2VAZ2x1dS5vcmc+PiB3cm90ZToNCg0KDQpJIGRvbid0IGtub3cgaWYgYSBGSURPIGNyZWRl
bnRpYWwgaXMgcmVhbGx5IGEgZGV2aWNlLiBJdCdzIGEgZmFuY3kgcGFzc3dvcmQgd2l0aCBsb3Rz
IG9mIG1ldGFkYXRhLg0KDQotIE1pa2UNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpNaWNoYWVsIFNjaHdhcnR6DQpHbHV1DQpGb3VuZGVyIC8gQ0VPDQptaWtlQGds
dXUub3JnPG1haWx0bzptaWtlQGdsdXUub3JnPg0KDQpPbiAyMDE2LTA4LTIwIDExOjM2LCBLZWl0
aCBIYXplbHRvbiB3cm90ZToNCkFsbCwNCklmIEmhr20gY29ycmVjdCwgU0NJTSBoYXNuoa90IHll
dCBkZWZpbmVkIGEgRGV2aWNlIHJlc291cmNlIG9yIHNjaGVtYS4NClRoYXQgd291bGQgbWVhbiB3
ZSBjb3VsZCBwcm9jZWVkIGluIHR3byBzdGVwczogRGVmaW5lIGFuZCByZWdpc3RlciBhDQpTQ0lN
IERldmljZSBzY2hlbWEgdGhhdCBjYXJyaWVzIGF0dHJpYnV0ZXMgY29tbW9uIHRvIGFsbCBkZXZp
Y2VzLCBhbmQNCnRoZW4gMikgRGVmaW5lIGFuZCByZWdpc3RlciBhIFNDSU0gcmVzb3VyY2UgdHlw
ZSBhbmQgZXh0ZW5zaW9uIHNjaGVtYQ0KZm9yIEZJRE8gZGV2aWNlcyB0aGF0IGFkZCBhbGwgdGhl
IEZJRE8tc3BlY2lmaWMgYXR0cmlidXRlcy4NCiAgICAgICAtLUtlaXRoDQplbWFpbCAmIGphYmJl
cjoga2VpdGguaGF6ZWx0b25Ad2lzYy5lZHU8bWFpbHRvOmtlaXRoLmhhemVsdG9uQHdpc2MuZWR1
Pg0KY2FsZW5kYXI6IGh0dHA6Ly9nby53aXNjLmVkdS9pNnp4eDANCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPbiAyMDE2LTA4LTIwLCAxMTowMiAsICJzY2ltIG9uIGJlaGFsZiBv
ZiBNaWtlIFNjaHdhcnR6Ig0KPHNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3Vu
Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgbWlrZUBnbHV1Lm9yZzxtYWlsdG86bWlrZUBnbHV1
Lm9yZz4+IHdyb3RlOg0KICAgTW9ydGV6YSwNCiAgIFRoYW5rcyBmb3IgdGhlIG9mZmVyLiBXZSdk
IGRlZmluaXRlbHkgYXBwcmVjaWF0ZSBhbnkgaGVscCBvciBmZWVkYmFjay4NCiAgIEkgd2FzIHdv
bmRlcmluZyBhYm91dCBEZXZpY2UuIEkgd2FzIGNvbmNlcm5lZCB0aGF0IG15IGlkZWEgZm9yIGEg
ZGV2aWNlDQogICB3YXMgc29tZXRoaW5nIGxpa2UgYSBzbWFydCBwaG9uZSwgYW5kIEZJRE8gZGV2
aWNlcyBhcmUgbW9yZSBsaW1pdGVkLiBXZQ0KICAgZW5kZWQgdXAgZGVjaWRpbmcgdG8gZGVmaW5l
IGEgbmV3IHJlc291cmNlIHR5cGUgY2FsbGVkICJGaWRvRGV2aWNlIg0KICAgTW9yZSBkZXRhaWxz
IG9mIHRoZSBkZXNpZ24gYW5kIHJlcXVpcmVtZW50cyB3ZXJlIGRvY3VtZW50ZWQgb24gdGhpcw0K
ICAgZ2l0aHViIGlzc3VlOg0KICAgICAgaHR0cHM6Ly9naXRodWIuY29tL0dsdXVGZWRlcmF0aW9u
L294QXV0aC9pc3N1ZXMvMjI2DQogICBXZSB3YW50IHRoaXMgdG8gc3VwcG9ydCB0aGUgVTJGLCBV
QUYgYW5kIEZJRE8yIGRldmljZXMgb2YgYSBwZXJzb24uDQogICAtIE1pa2UNCiAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgIE1pY2hhZWwgU2Nod2FydHoNCiAgIEds
dXUNCiAgIEZvdW5kZXIgLyBDRU8NCiAgIG1pa2VAZ2x1dS5vcmc8bWFpbHRvOm1pa2VAZ2x1dS5v
cmc+DQogICBPbiAyMDE2LTA4LTE5IDE2OjU2LCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIHdy
b3RlOg0KICAgPiBIaSBNaWtlLA0KICAgPg0KICAgPiBIYXZlIHlvdSBjb25zaWRlcmVkIGRvaW5n
IGEgZGV2aWNlIG9iamVjdCBhbmQgYW4gZXh0ZW5zaW9uIGZvciBGaWRvDQogICA+IGJpdHM/DQog
ICA+IEkgdGhpbmsgZGV2aWNlIGlzIGEgZ2VuZXJpYyBvYmplY3QgdGhhdCB3b3VsZCBiZSBoZWxw
ZnVsIHRvIGRlZmluZSBhbmQNCiAgID4gZXh0ZW5kIGluIGEgcmVhc29uYWJseSBjb21tb24gd2F5
cy4gIEkgYW0gd2lsbGluZyB0byB3b3JrIG9uIHRoYXQgaWYNCiAgID4geW91DQogICA+IGFyZSBp
bnRlcmVzdGVkLiBXZSBoYWQgdGFsa2VkIGFib3V0IHRoaXMgYSBmZXcgdGltZXMgYnV0IGRpZG6p
9nQgaGF2ZQ0KICAgPiBjb25jcmV0ZSBleGFtcGxlcyBiZXlvbmQgc29tZSBvZiB0aGUgdGhpbmdz
IGVhY2ggb2YgdXMgaGFkIGRvbmUNCiAgID4gaW5kaXZpZHVhbGx5Lg0KICAgPg0KICAgPg0KICAg
PiBDaGVlcnMsDQogICA+IE1vcnRlemENCiAgID4NCiAgID4gT24gOC8xNy8xNiwgNzoyMCBQTSwg
InNjaW0gb24gYmVoYWxmIG9mIE1pa2UgU2Nod2FydHoiDQogICA+IDxzY2ltLWJvdW5jZXNAaWV0
Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1pa2VAZ2x1
dS5vcmc8bWFpbHRvOm1pa2VAZ2x1dS5vcmc+PiB3cm90ZToNCiAgID4NCiAgID4+DQogICA+PiBT
Q0lNIGd1cnVzLA0KICAgPj4NCiAgID4+IFdlIGRlY2lkZWQgdG8gZGVmaW5lIGEgbmV3IHJlc291
cmNlIHR5cGUgbmFtZWQgIkZpZG9EZXZpY2UiLg0KICAgPj4NCiAgID4+IElmIHlvdSdyZSBjdXJp
b3VzIGFib3V0IHRoZSBkZXNpZ246DQogICA+PiBodHRwczovL2dpdGh1Yi5jb20vR2x1dUZlZGVy
YXRpb24vb3hBdXRoL2lzc3Vlcy8yMjYNCiAgID4+DQogICA+PiAtIE1pa2UNCiAgID4+DQogICA+
PiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgPj4gTWljaGFlbCBT
Y2h3YXJ0eg0KICAgPj4gR2x1dQ0KICAgPj4gaHR0cDovL2dsdXUub3JnDQogICA+Pg0KICAgPj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgID4+IHNj
aW0gbWFpbGluZyBsaXN0DQogICA+PiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3Jn
Pg0KICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQogICBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgc2NpbSBt
YWlsaW5nIGxpc3QNCiAgIHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQogICBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpz
Y2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg==

--_000_D3E1B51644796moransarciscocom_
Content-Type: text/html; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13
cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i
cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog
MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+VG8gYmUgY2xl
YXIgSSB3YXMgc3VnZ2VzdGluZyBhIHRvcCBsZXZlbCBlbmRwb2ludCBsaWtlIC9kZXZpY2VzIGFu
ZCBjb3JlIHNjaGVtYSBmb3IgdGhlIGRldmljZSBpdHNlbGYgcGx1cyBleHRlbnNpb25zIGZvciBG
SURPLiBUaGlzIHdheSB3ZSBoYXZlIGEgcGxhY2UgdG8gZXh0ZW5kIHRoZSBkZXZpY2UgY2xhc3Mg
YW5kIGhhbmcgYW55IGFkZGl0aW9uYWwgZGV2aWNlIGV4dGVuc2lvbnMuIERldmljZXMgYXJlIG5v
dCBhbGwgRklETyBvciBjZWxsDQogcGhvbmUgb3KhpjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsg
Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE
RElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsg
Qk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7
IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206
IDwvc3Bhbj5QaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5EYXRlOiA8L3NwYW4+U2F0dXJkYXksIEF1Z3VzdCAyMCwgMjAxNiBhdCAxMjoy
NiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPk1pa2Ug
U2Nod2FydHogJmx0OzxhIGhyZWY9Im1haWx0bzptaWtlQGdsdXUub3JnIj5taWtlQGdsdXUub3Jn
PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5L
ZWl0aCBIYXplbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmhhemVsdG9uQHdpc2MuZWR1
Ij5rZWl0aC5oYXplbHRvbkB3aXNjLmVkdTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86
c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiZndDssIE1vcnRlemEgJmx0OzxhIGhy
ZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iPm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTog
W3NjaW1dIEZJRE8gQ3JlZCBNZ3QgdmlhIFNDSU08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i
c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj
bGFzcz0iIj4NClNvbWV0aGluZyB0byBkaXNjdXNzIGlzIHdoYXQgc2hvdWxkIGJlIGFuIGV4dGVu
c2lvbiBvZiBVc2VyIHZzLiBEZXZpY2UgYW5kIHdoYXQgdGhlIHJlZmVyZW5jZXMgYXJlIGluIGJl
dHdlZW4uDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5JdCBtYXkgYmUgdXNlZnVsIHRvIGFsc28gdHJhY2sgdG9rZW4gYmluZGluZyByZWxhdGlvbnNo
aXBzIHRvby48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7
IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh
bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFr
LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl
ci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBw
bGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGxpbmUtaGVp
Z2h0OiBub3JtYWw7IGJvcmRlci1zcGFjaW5nOiAwcHg7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9
IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0
LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+UGhpbDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QGluZGVwZW5kZW50aWQ8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSIgY2xhc3M9IiI+
d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgY2xhc3M9IiIgc3R5
bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNz
PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p
bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu
ZSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDIwLCAyMDE2LCBhdCAxMjowOSBQTSwg
TWlrZSBTY2h3YXJ0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2VAZ2x1dS5vcmciIGNsYXNzPSIi
Pm1pa2VAZ2x1dS5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50
ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQpJIGRvbid0IGtub3cgaWYgYSBGSURPIGNyZWRlbnRpYWwgaXMgcmVhbGx5IGEgZGV2
aWNlLiBJdCdzIGEgZmFuY3kgcGFzc3dvcmQgd2l0aCBsb3RzIG9mIG1ldGFkYXRhLjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCi0gTWlrZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIg
Y2xhc3M9IiI+DQpNaWNoYWVsIFNjaHdhcnR6PGJyIGNsYXNzPSIiPg0KR2x1dTxiciBjbGFzcz0i
Ij4NCkZvdW5kZXIgLyBDRU88YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bWlrZUBnbHV1
Lm9yZyIgY2xhc3M9IiI+bWlrZUBnbHV1Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQpPbiAyMDE2LTA4LTIwIDExOjM2LCBLZWl0aCBIYXplbHRvbiB3cm90ZTo8YnIgY2xhc3M9
IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BbGwsPGJyIGNsYXNzPSIiPg0K
SWYgSaGvbSBjb3JyZWN0LCBTQ0lNIGhhc26hr3QgeWV0IGRlZmluZWQgYSBEZXZpY2UgcmVzb3Vy
Y2Ugb3Igc2NoZW1hLjxiciBjbGFzcz0iIj4NClRoYXQgd291bGQgbWVhbiB3ZSBjb3VsZCBwcm9j
ZWVkIGluIHR3byBzdGVwczogRGVmaW5lIGFuZCByZWdpc3RlciBhPGJyIGNsYXNzPSIiPg0KU0NJ
TSBEZXZpY2Ugc2NoZW1hIHRoYXQgY2FycmllcyBhdHRyaWJ1dGVzIGNvbW1vbiB0byBhbGwgZGV2
aWNlcywgYW5kPGJyIGNsYXNzPSIiPg0KdGhlbiAyKSBEZWZpbmUgYW5kIHJlZ2lzdGVyIGEgU0NJ
TSByZXNvdXJjZSB0eXBlIGFuZCBleHRlbnNpb24gc2NoZW1hPGJyIGNsYXNzPSIiPg0KZm9yIEZJ
RE8gZGV2aWNlcyB0aGF0IGFkZCBhbGwgdGhlIEZJRE8tc3BlY2lmaWMgYXR0cmlidXRlcy48YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLUtl
aXRoPGJyIGNsYXNzPSIiPg0KZW1haWwgJmFtcDsgamFiYmVyOiA8YSBocmVmPSJtYWlsdG86a2Vp
dGguaGF6ZWx0b25Ad2lzYy5lZHUiPmtlaXRoLmhhemVsdG9uQHdpc2MuZWR1PC9hPjxiciBjbGFz
cz0iIj4NCmNhbGVuZGFyOiA8YSBocmVmPSJodHRwOi8vZ28ud2lzYy5lZHUvaTZ6eHgwIj5odHRw
Oi8vZ28ud2lzYy5lZHUvaTZ6eHgwPC9hPjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT24gMjAxNi0wOC0yMCwgMTE6MDIgLCAmcXVv
dDtzY2ltIG9uIGJlaGFsZiBvZiBNaWtlIFNjaHdhcnR6JnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmx0
OzxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciPnNjaW0tYm91bmNlc0BpZXRm
Lm9yZzwvYT4gb24gYmVoYWxmIG9mIDxhIGhyZWY9Im1haWx0bzptaWtlQGdsdXUub3JnIj4NCm1p
a2VAZ2x1dS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz
cDtNb3J0ZXphLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rcyBmb3IgdGhl
IG9mZmVyLiBXZSdkIGRlZmluaXRlbHkgYXBwcmVjaWF0ZSBhbnkgaGVscCBvciBmZWVkYmFjay48
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtJIHdhcyB3b25kZXJpbmcgYWJvdXQgRGV2
aWNlLiBJIHdhcyBjb25jZXJuZWQgdGhhdCBteSBpZGVhIGZvciBhIGRldmljZTxiciBjbGFzcz0i
Ij4NCiZuYnNwOyZuYnNwOyZuYnNwO3dhcyBzb21ldGhpbmcgbGlrZSBhIHNtYXJ0IHBob25lLCBh
bmQgRklETyBkZXZpY2VzIGFyZSBtb3JlIGxpbWl0ZWQuIFdlPGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7ZW5kZWQgdXAgZGVjaWRpbmcgdG8gZGVmaW5lIGEgbmV3IHJlc291cmNlIHR5
cGUgY2FsbGVkICZxdW90O0ZpZG9EZXZpY2UmcXVvdDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz
cDsmbmJzcDtNb3JlIGRldGFpbHMgb2YgdGhlIGRlc2lnbiBhbmQgcmVxdWlyZW1lbnRzIHdlcmUg
ZG9jdW1lbnRlZCBvbiB0aGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Z2l0aHVi
IGlzc3VlOjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9HbHV1RmVkZXJhdGlvbi9veEF1dGgvaXNzdWVz
LzIyNiI+aHR0cHM6Ly9naXRodWIuY29tL0dsdXVGZWRlcmF0aW9uL294QXV0aC9pc3N1ZXMvMjI2
PC9hPjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO1dlIHdhbnQgdGhpcyB0byBzdXBw
b3J0IHRoZSBVMkYsIFVBRiBhbmQgRklETzIgZGV2aWNlcyBvZiBhIHBlcnNvbi48YnIgY2xhc3M9
IiI+DQombmJzcDsmbmJzcDsmbmJzcDstIE1pa2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm
bmJzcDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7TWljaGFlbCBTY2h3YXJ0ejxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwOyZuYnNwO0dsdXU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtGb3VuZGVyIC8g
Q0VPPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1pa2VA
Z2x1dS5vcmciPm1pa2VAZ2x1dS5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7T24gMjAxNi0wOC0xOSAxNjo1NiwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSB3cm90ZTo8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IEhpIE1pa2UsPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZndDsgSGF2ZSB5b3UgY29uc2lkZXJlZCBkb2luZyBhIGRldmljZSBvYmplY3QgYW5kIGFuIGV4
dGVuc2lvbiBmb3IgRmlkbzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsgYml0
cz88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IEkgdGhpbmsgZGV2aWNlIGlz
IGEgZ2VuZXJpYyBvYmplY3QgdGhhdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGRlZmluZSBhbmQ8YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IGV4dGVuZCBpbiBhIHJlYXNvbmFibHkg
Y29tbW9uIHdheXMuICZuYnNwO0kgYW0gd2lsbGluZyB0byB3b3JrIG9uIHRoYXQgaWY8YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IHlvdTxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZndDsgYXJlIGludGVyZXN0ZWQuIFdlIGhhZCB0YWxrZWQgYWJvdXQgdGhpcyBh
IGZldyB0aW1lcyBidXQgZGlkbqn2dCBoYXZlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jmd0OyBjb25jcmV0ZSBleGFtcGxlcyBiZXlvbmQgc29tZSBvZiB0aGUgdGhpbmdzIGVhY2gg
b2YgdXMgaGFkIGRvbmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IGluZGl2
aWR1YWxseS48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZndDsgQ2hlZXJzLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsgTW9ydGV6
YTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJz
cDsmbmJzcDsmbmJzcDsmZ3Q7IE9uIDgvMTcvMTYsIDc6MjAgUE0sICZxdW90O3NjaW0gb24gYmVo
YWxmIG9mIE1pa2UgU2Nod2FydHomcXVvdDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz
cDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5zY2ltLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOm1pa2VAZ2x1
dS5vcmciPm1pa2VAZ2x1dS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQombmJzcDsm
bmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZndDs8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jmd0OyBTQ0lNIGd1cnVzLDxiciBj
bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jmd0OyZndDsgV2UgZGVjaWRlZCB0byBkZWZpbmUgYSBuZXcgcmVzb3VyY2Ug
dHlwZSBuYW1lZCAmcXVvdDtGaWRvRGV2aWNlJnF1b3Q7LjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZn
dDsgSWYgeW91J3JlIGN1cmlvdXMgYWJvdXQgdGhlIGRlc2lnbjo8YnIgY2xhc3M9IiI+DQombmJz
cDsmbmJzcDsmbmJzcDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vR2x1dUZl
ZGVyYXRpb24vb3hBdXRoL2lzc3Vlcy8yMjYiPmh0dHBzOi8vZ2l0aHViLmNvbS9HbHV1RmVkZXJh
dGlvbi9veEF1dGgvaXNzdWVzLzIyNjwvYT48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz
cDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7IC0gTWlr
ZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZndDsgJm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7IE1p
Y2hhZWwgU2Nod2FydHo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jmd0OyBH
bHV1PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZndDsgPGEgaHJlZj0iaHR0
cDovL2dsdXUub3JnIj5odHRwOi8vZ2x1dS5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jmd0
OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz
cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7IHNjaW0gbWFpbGluZyBsaXN0PGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNjaW1A
aWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PGJy
IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtzY2lt
IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Im1h
aWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZuYnNw
OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxi
ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2NpbSBtYWls
aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2Np
bUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vc2NpbTwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
Cjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D3E1B51644796moransarciscocom_--


From nobody Tue Aug 23 08:36:43 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A612D5C0 for ; Tue, 23 Aug 2016 08:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level: 
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 9GSiBUBV98Q0 for ; Tue, 23 Aug 2016 08:36:39 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF69C12D95E for ; Tue, 23 Aug 2016 08:27:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id D64CBB41F4 for ; Tue, 23 Aug 2016 15:27:07 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1471966027; x=1472830028; bh=3CdzlIGCKv vlhOMXrr7hUGSE9E6OLoYUUggNNqu7ka4=; b=GLZvc+0Z6IpCVHDMQjYJz7/hO+ iMKbTxqt7k9IAvG0qOJdR1Em5NekAIcGFlK1RZFhK5jJHsBKQCq/zX/SlOoGizUU qgoWIjwrK5/Mj7L+gOWpo9qQM2AmHattQLGkubrUt81nqfJXKHvGxzvHBnDmSEmW y3wmplM+Ho8HjtZRY=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOYPiM5A_5ZP for ; Tue, 23 Aug 2016 15:27:07 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 1BF2FB40DD; Tue, 23 Aug 2016 15:27:07 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 23 Aug 2016 10:27:06 -0500
From: Mike Schwartz 
To: "Morteza Ansari (moransar)" 
Organization: Gluu
In-Reply-To: 
References:    <614E4025-A303-4C33-BAEE-040641435D99@wisc.edu> <304f70e47df3ff301e7b8acf6ab03e61@gluu.org>  
Message-ID: <3df44f44defc5df176027d5d4ee582ad@gluu.org>
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Cc: scim@ietf.org, Keith Hazelton , Phil Hunt 
Subject: Re: [scim] FIDO Cred Mgt via SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2016 15:36:41 -0000

Something like /FidoDevices, like what we did in our custom resource 
type?

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org

On 2016-08-23 10:11, Morteza Ansari (moransar) wrote:
> To be clear I was suggesting a top level endpoint like /devices and
> core schema for the device itself plus extensions for FIDO. This way
> we have a place to extend the device class and hang any additional
> device extensions. Devices are not all FIDO or cell phone or…
> 
>  From: Phil Hunt 
> Date: Saturday, August 20, 2016 at 12:26 PM
> To: Mike Schwartz 
> Cc: Keith Hazelton , "scim@ietf.org"
> , Morteza 
> Subject: Re: [scim] FIDO Cred Mgt via SCIM
> 
>  Something to discuss is what should be an extension of User vs.
> Device and what the references are in between.
> 
> It may be useful to also track token binding relationships too.
> 
> Phil
> 
> @independentid
> www.independentid.com [1] phil.hunt@oracle.com
> 
>> On Aug 20, 2016, at 12:09 PM, Mike Schwartz  wrote:
>> 
>> I don't know if a FIDO credential is really a device. It's a fancy
>> password with lots of metadata.
>> 
>> - Mike
>> 
>> -------------------------------------
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> mike@gluu.org
>> 
>> On 2016-08-20 11:36, Keith Hazelton wrote:
>> 
>>> All,
>>> If I’m correct, SCIM hasn’t yet defined a Device resource or
>>> schema.
>>> That would mean we could proceed in two steps: Define and register
>>> a
>>> SCIM Device schema that carries attributes common to all devices,
>>> and
>>> then 2) Define and register a SCIM resource type and extension
>>> schema
>>> for FIDO devices that add all the FIDO-specific attributes.
>>> --Keith
>>> email & jabber: keith.hazelton@wisc.edu
>>> calendar: http://go.wisc.edu/i6zxx0
>>> ________________________________
>>> On 2016-08-20, 11:02 , "scim on behalf of Mike Schwartz"
>>>  wrote:
>>> Morteza,
>>> Thanks for the offer. We'd definitely appreciate any help or
>>> feedback.
>>> I was wondering about Device. I was concerned that my idea for
>>> a device
>>> was something like a smart phone, and FIDO devices are more
>>> limited. We
>>> ended up deciding to define a new resource type called
>>> "FidoDevice"
>>> More details of the design and requirements were documented on
>>> this
>>> github issue:
>>> https://github.com/GluuFederation/oxAuth/issues/226
>>> We want this to support the U2F, UAF and FIDO2 devices of a
>>> person.
>>> - Mike
>>> -------------------------------------
>>> Michael Schwartz
>>> Gluu
>>> Founder / CEO
>>> mike@gluu.org
>>> On 2016-08-19 16:56, Morteza Ansari (moransar) wrote:
>>>> Hi Mike,
>>>> 
>>>> Have you considered doing a device object and an extension
>>> for Fido
>>>> bits?
>>>> I think device is a generic object that would be helpful to
>>> define and
>>>> extend in a reasonably common ways.  I am willing to work on
>>> that if
>>>> you
>>>> are interested. We had talked about this a few times but
>>> didn¹t have
>>>> concrete examples beyond some of the things each of us had
>>> done
>>>> individually.
>>>> 
>>>> 
>>>> Cheers,
>>>> Morteza
>>>> 
>>>> On 8/17/16, 7:20 PM, "scim on behalf of Mike Schwartz"
>>>>  wrote:
>>>> 
>>>>> 
>>>>> SCIM gurus,
>>>>> 
>>>>> We decided to define a new resource type named "FidoDevice".
>>>>> 
>>>>> If you're curious about the design:
>>>>> https://github.com/GluuFederation/oxAuth/issues/226
>>>>> 
>>>>> - Mike
>>>>> 
>>>>> -------------------------------------
>>>>> Michael Schwartz
>>>>> Gluu
>>>>> http://gluu.org
>>>>> 
>>>>> _______________________________________________
>>>>> 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/mailman/listinfo/scim
> 
> 
> 
> Links:
> ------
> [1] http://www.independentid.com


From nobody Wed Aug 24 13:24:29 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD62B12D67C for ; Wed, 24 Aug 2016 13:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Vu7gdBckYYyo for ; Wed, 24 Aug 2016 13:24:25 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6627512B02C for ; Wed, 24 Aug 2016 13:24:25 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id e63so233036145ith.1 for ; Wed, 24 Aug 2016 13:24:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WKcsf1cVBBTOzHHW+zeuMLyeM9BVe9EFIGyxWQJaKYM=; b=PmzVHhh9KY6oxMEG2J4zINwI0Z0cA0xCtdS1AWTzjfaKB7QhdwusXqZF0YSPtmqRCh 826OatWKfbQk49s9+fw/zCf6T8rEbMCwCNk6cqEZ5t9PXEVjVmFKMBzRJvEFloHubvph +woUMqC49bAmVagaJx6mhIQXHgqffAfiiUaxBuxSiXOrlIXukI0TVRZCkLIxq3s5vy4M 9QMjHJy/laSPY2uJP98hddngjHk2rw2KcpoqQef0/kZRto9kmqNWRZsXQ7gVfdReRRLi EEAh2deAuSqxwAmy/ovest5xI5iA8WH8WhkaENw4D84UCsRFTHXC37gRIcX5oOEdJlXN 6cXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WKcsf1cVBBTOzHHW+zeuMLyeM9BVe9EFIGyxWQJaKYM=; b=Sfknsb28LV18s3xcmXecD+73vw1Xxpz0n/UjT5qmNuxY127IQraDCt9OO7P+C4BLSc skO112qv5hIyTyQkIDpuu76bmHq0z59tfeV/ljkyQK0mD1klaUoFvWjIsolqGZYcsvXm ++IpAIDamO2dLdXmkGbuSDRknsPzF3j3TI8GfRiUTh0VqtWhqLlONS1jn+Jrv9Dsl7AV xUsAVp1uAnF+z5sC3FGgWmTZuvixUekHKi7hwSaYlIvAs6fAIkr3Gd1kmMybRuioILgg xVm8AkHaA78EHzL3WSL3xf/i1TM2hza3vC+QI3XuF3DmrR/63aacK69Llg2vLgmsfNMR t7bw==
X-Gm-Message-State: AEkoouvo7LCpAqadnygX6fCL5oExaMUpv3fEIKFmT4LPzG7RStEYavkXBDzXaPzGypO/3CBgvl+4xQYwJcdTHA==
X-Received: by 10.36.99.2 with SMTP id j2mr912873itc.72.1472070264704; Wed, 24 Aug 2016 13:24:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.163.71 with HTTP; Wed, 24 Aug 2016 13:24:23 -0700 (PDT)
In-Reply-To: <5756FC73-84F0-4564-8546-29A93A8373FA@mnt.se>
References:     <5756FC73-84F0-4564-8546-29A93A8373FA@mnt.se>
From: Shelley 
Date: Wed, 24 Aug 2016 15:24:23 -0500
Message-ID: 
To: Leif Johansson 
Content-Type: multipart/alternative; boundary=001a113acda0365479053ad71185
Archived-At: 
Cc: "scim@ietf.org WG" , Ian Glazer , Kelly Grizzle 
Subject: Re: [scim] Cardinality
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2016 20:24:28 -0000

--001a113acda0365479053ad71185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> What=E2=80=99s the best way to capture these?  The SCIM issue tracker?  S=
tart a
> github project for tracking?  Just chase them down over email?  It would =
be
> good to have another meeting where we can figure out how to tackle these.
>
> +1 for github issues
>


We have been recently been reviewing the SCIM 2.0 specification in detail,
and have also noticed a few ambiguities and potential mistakes in the
specification that we would like to log. Will there be an issue tracker
available soon, or should we continue to post any issues to this mailing
list?


On Tue, Aug 16, 2016 at 2:23 PM, Leif Johansson  wrote:

>
>
> Skickat fr=C3=A5n min iPhone
>
> 16 aug. 2016 kl. 20:37 skrev Kelly Grizzle :
>
> I agree that we should at least have some way to indicate if an attribute
> has these types of limitations (like Ian said =E2=80=A6 the schema is a p=
erfect
> place for this).  The question about what to do if someone doesn=E2=80=99=
t adhere
> to this also deserves some discussion.
>
>
>
> I have a list of issues/thoughts from the interop that I was supposed to
> put on the list, but have not had a chance to yet.  Sorry!
>
>
>
> What=E2=80=99s the best way to capture these?  The SCIM issue tracker?  S=
tart a
> github project for tracking?  Just chase them down over email?  It would =
be
> good to have another meeting where we can figure out how to tackle these.
>
>
> +1 for github issues
>
>
>
> --Kelly
>
>
>
> *From:* scim [mailto:scim-bounces@ietf.org ] *On
> Behalf Of *Ian Glazer
> *Sent:* Tuesday, August 16, 2016 10:22 AM
> *To:* Leif Johansson 
> *Cc:* scim@ietf.org WG 
> *Subject:* Re: [scim] Cardinality
>
>
>
> It would be good to have at least one more WG meeting so that we can get =
a
> grab off all these items. It would also be good if said meeting was
> scheduled such that Shalini and the Google team could attend.
>
>
>
> On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson  wrote:
>
> Is somebody maintaining an issue list somewhere? Maybe dump the current
> rfcs in github...
>
> Skickat fr=C3=A5n min iPhone
>
>
> 16 aug. 2016 kl. 16:28 skrev Ian Glazer :
>
> Hey gang -
>
>
>
> Coming out of the interop one thing that I'd definitely like to see is a
> way to represent cardinality in the schema. Case in point, the spec state=
s
> that email is a multivalued attribute, but we only support a single email
> address. In order to comply with the spec, we have to represent it as
> mutlivalued and then we throw an error if someone tries to add more than
> one. Not optimal. I suggest a schema attribute of MaximumCardinality of
> type number. The number represents the maximum entries for a multivalued
> attribute. If not set, then it is implied there is no limit.
>
>
>
> --
>
> Ian Glazer
>
> Senior Director, Identity
>
> +1 202 255 3166
>
> @iglazer 
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>
>
>
>
> --
>
> Ian Glazer
>
> Senior Director, Identity
>
> +1 202 255 3166
>
> @iglazer 
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>

--001a113acda0365479053ad71185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


What=E2=
=80=99s
 the best way to capture these?=C2=A0 The SCIM issue tracker?=C2=A0 Start a=
 github
 project for tracking?=C2=A0 Just chase them down over email?=C2=A0 It woul=
d be=20
good to have another meeting
 where we can figure out how to tackle these.
+1 for github issues

We have been recently been reviewing the SCIM 2.0 specification in detail,=
 and have also noticed a few ambiguities and potential mistakes in the spec=
ification that we would like to log. Will there be an issue tracker availab=
le soon, or should we continue to post any issues to this mailing list?
=



On Tue, Aug 1=
6, 2016 at 2:23 PM, Leif Johansson <leifj@mnt.se> wrote:

Skickat fr=C3=A5n min iPhone

16 aug. 2016 k=
l. 20:37 skrev Kelly Grizzle <kelly.grizzle@sailpoint.com>:











I agree that we should at least have some way to indi=
cate if an attribute has these types of limitations (like Ian said =E2=80=
=A6 the schema is a perfect place for this).=C2=A0 The question
 about what to do if someone doesn=E2=80=99t adhere to this also deserves s=
ome discussion.


=C2=A0


I have a list of issues/thoughts from the interop tha=
t I was supposed to put on the list, but have not had a chance to yet.=C2=
=A0 Sorry!


=C2=A0


What=E2=80=99s the best way to capture these?=C2=A0 T=
he SCIM issue tracker?=C2=A0 Start a github project for tracking?=C2=A0 Jus=
t chase them down over email?=C2=A0 It would be good to have another meetin=
g
 where we can figure out how to tackle these.

+1 for github issues



=C2=A0


--Kelly


=C2=A0


From: scim [mailto:scim-bounces@ietf.org]
On Behalf Of Ian Glazer

Sent: Tuesday, August 16, 2016 10:22 AM

To: Leif Johansson <leifj@mnt.se>

Cc: scim@ietf.org=
 WG <scim@ietf.or=
g>

Subject: Re: [scim] Cardinality


=C2=A0




It would be good to have at least one more WG meetin=
g so that we can get a grab off all these items. It would also be good if s=
aid meeting was scheduled such that Shalini and the Google team could atten=
d.






=C2=A0




On Tue, Aug 16, 2016 at 10:32 AM, Leif Johansson <=
;leifj@mnt.se> wro=
te:








Is somebody maintaining an issue list somewhere? May=
be dump the current rfcs in github...



Skickat fr=C3=A5n min iPhone












16 aug. 2016 kl. 16:28 skrev Ian Glazer <iglazer@salesforce.com>:<=
/p>









Hey gang -




=C2=A0






Coming out of the interop one thing that I'd def=
initely like to see is a way to represent cardinality in the schema. Case i=
n point, the spec states that email is a multivalued attribute, but we only=
 support a single email address. In order
 to comply with the spec, we have to represent it as mutlivalued and then w=
e throw an error if someone tries to add more than one. Not optimal. I sugg=
est a schema attribute of MaximumCardinality of type number. The number rep=
resents the maximum entries for
 a multivalued attribute. If not set, then it is implied there is no limit.=







=C2=A0




-- 








Ian Glazer






Senior Director, Identity




























_______________________________________________=


scim mailing list

scim@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/scim





















=C2=A0




-- 








Ian Glazer






Senior Director, Identity

















_______________________________________________

scim mailing list

scim@ietf.org

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





--001a113acda0365479053ad71185--


From nobody Thu Aug 25 09:08:26 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBE612D603 for ; Thu, 25 Aug 2016 09:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rEs08cJNu9Jo for ; Thu, 25 Aug 2016 09:08:23 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6FF12D0E2 for ; Thu, 25 Aug 2016 09:08:23 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id e63so280757009ith.1 for ; Thu, 25 Aug 2016 09:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=2AlifRa2khTjUokyCUApkWMQuXvymUzLGsIXMA71Qzo=; b=Zja/IYwg1k+dx8Sw1FpTQR6bEXqHjOlPvzFHakkwRswPWJso9LFDaF9SUCrUCpM5Rm JbD1r6ql1IAofdq3Lgh8hpsngLHrfCrpdYL0auudunD2GeS5qH75rkyCxALwhS+4O/Kp M2VwsZlR5zkyMmI1ep3l55fVQvfKyJ8qnt9w2fcK81S0/QX83zIS6cPnjBNCoOJScvUy lbaI/VwA4+ymAwGaHO1UlrljVtl4okZmSMT4n2b5EQXmici2pSbMSQk/34dftB3VxqFC 57qbEt3iXwPx4D2x8qdl1zB7FsA1oDVi01zmgDXhftV4Sy7cxUo+mu1+nznmliOqjPXF IY7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2AlifRa2khTjUokyCUApkWMQuXvymUzLGsIXMA71Qzo=; b=ARBA/s5rKqxUypXBfiJLtwKLyehwad8hh7OR58r3xJmR0dUOBq4W6VFHGWeI08rTBy VKGETupAwrQa8TwXvR0W8RGgK++ikSWoaVdZeT7Y7l2ZezfCPf0yWxlSsHyDaFL5+TH4 1xieH3kOXDmcbuqItF70OWm93dPkZGXZoACyFt6bQm85Dw4Inem1Mv1fSiIWSN2rkbou 4q5boKXTb5rp9QGX9q+mpZfLlHHLuizAIxOhOxiw+LCRAqH8DbvRJs7IlY8MHxXlSj5c CK2pcoedLFjSHUU0dgtAsEkwpGvhfhjM96GitZGTVrX49fCIRRCSA4J7ms2HVPiW9p7Q 6Clw==
X-Gm-Message-State: AEkoousxSsZwALjCUEGgB0Pj97PWIGwDlZrgb+wM6Oz+8uGCNmoD981K6czsC4OM1CWg6tXwTwfhv+DY0sz5ng==
X-Received: by 10.36.99.2 with SMTP id j2mr5935329itc.72.1472141302485; Thu, 25 Aug 2016 09:08:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.163.71 with HTTP; Thu, 25 Aug 2016 09:08:22 -0700 (PDT)
From: Shelley 
Date: Thu, 25 Aug 2016 11:08:22 -0500
Message-ID: 
To: "scim@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113acda06502c9053ae79ba3
Archived-At: 
Subject: [scim] Search Endpoint Requirements
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2016 16:08:24 -0000

--001a113acda06502c9053ae79ba3
Content-Type: text/plain; charset=UTF-8

Is the *.search* endpoint [1] *required *for service providers to implement?

Further, are the *attributes within a search request* subject to the *service
provider config*? If, for example, a Service Provider supports sorting but
does *not *support filtering, what is the expected response when a client
includes a filter in the .search? Should the unsupported attributes simply
be ignored?

[1] https://tools.ietf.org/html/rfc7644#section-3.4.3

--001a113acda06502c9053ae79ba3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Is the .search endpoint [1] required for service providers to implement?

Further, are the attribu=
tes within a search request subject to the service provider config? If, for example, a Service Provider supports sorting but does not support filtering, what is the expected response when a client includes a=
 filter in the .search? Should the unsupported attributes simply be ignored=
?

[1] =
https://tools.ietf.org/html/rfc7644#section-3.4.3


--001a113acda06502c9053ae79ba3--


From nobody Thu Aug 25 09:27:32 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6B512D866 for ; Thu, 25 Aug 2016 09:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level: 
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 I6Pd3jYJPJCU for ; Thu, 25 Aug 2016 09:27:29 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 9D7D212D85E for ; Thu, 25 Aug 2016 09:27:29 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7PGRRmg029071 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Aug 2016 16:27:28 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7PGRRpx007620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 16:27:27 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7PGRLtU031269; Thu, 25 Aug 2016 16:27:26 GMT
Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Aug 2016 09:27:21 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBC3E0C3-DB2C-420C-A860-585135F575C7"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: 
Date: Thu, 25 Aug 2016 09:27:20 -0700
Message-Id: <8CC15A64-C9DF-418E-BBD0-DD1C8195C05F@oracle.com>
References: 
To: Shelley 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "scim@ietf.org" 
Subject: Re: [scim] Search Endpoint Requirements
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2016 16:27:31 -0000

--Apple-Mail=_FBC3E0C3-DB2C-420C-A860-585135F575C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Shelley,

inline=E2=80=A6

hope this helps=E2=80=A6

Phil

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






> On Aug 25, 2016, at 9:08 AM, Shelley  wrote:
>=20
> Is the .search endpoint [1] required for service providers to =
implement?

If my memory serves. No.  However, you need it if you need to pass PII =
or personally confidential information in a filter as otherwise it may =
leak through the URL (a privacy consideration).

The secondary reason is to allow a =E2=80=9Croot=E2=80=9D level search =
so clients can apply a filter searching for resources of more than one =
ResourceType.  There were cases where the client might not know if they =
were searching for a group or a user in a search-as-you-type series of =
searches.  Others are using as they are extending SCIM into IoT, =
devices, OAuth Clients, and other things.

>=20
> Further, are the attributes within a search request subject to the =
service provider config? If, for example, a Service Provider supports =
sorting but does not support filtering, what is the expected response =
when a client includes a filter in the .search? Should the unsupported =
attributes simply be ignored?

Not sure why you would implement .search if you aren=E2=80=99t using =
filters (given there is no PII issue).  All you could return (over =
normal GET) is all objects within the entire server which generally =
seems like something to be avoided except in a very small data set.

If the service provider config says filters are not supported then it =
should return HTTP Status 501 (not implemented) if a filter parameter is =
provided. =20


>=20
> [1] https://tools.ietf.org/html/rfc7644#section-3.4.3 =

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


--Apple-Mail=_FBC3E0C3-DB2C-420C-A860-585135F575C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Shelley,

inline=E2=80=A6

hope this helps=E2=80=A6








On Aug 25, 2016, at 9:08 AM, Shelley <randomshelley@gmail.com> wrote:

Is the .search endpoint [1] =
required for service providers to =
implement?

If my memory serves. No.  However, you need it if =
you need to pass PII or personally confidential information in a filter =
as otherwise it may leak through the URL (a privacy =
consideration).

The secondary reason =
is to allow a =E2=80=9Croot=E2=80=9D level search so clients can apply a =
filter searching for resources of more than one ResourceType. =
 There were cases where the client might not know if they were =
searching for a group or a user in a search-as-you-type series of =
searches.  Others are using as they are extending SCIM into IoT, =
devices, OAuth Clients, and other things.


Further, are the =
attributes within a search request subject to the service provider config? If, for example, a Service =
Provider supports sorting but does not support =
filtering, what is the expected response when a client includes a filter =
in the .search? Should the unsupported attributes simply be ignored?

Not sure why you would implement .search if you =
aren=E2=80=99t using filters (given there is no PII issue).  All =
you could return (over normal GET) is all objects within the entire =
server which generally seems like something to be avoided except in a =
very small data set.

If the service =
provider config says filters are not supported then it should return =
HTTP Status 501 (not implemented) if a filter parameter is provided. =
 



[1] =
https://tools.ietf.org/html/rfc7644#section-3.4.3

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

=

--Apple-Mail=_FBC3E0C3-DB2C-420C-A860-585135F575C7--


From nobody Tue Aug 30 20:51:12 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8212B00E for ; Tue, 30 Aug 2016 20:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ed2j8wc1MTs1 for ; Tue, 30 Aug 2016 20:51:09 -0700 (PDT)
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 538CC12D887 for ; Tue, 30 Aug 2016 20:51:09 -0700 (PDT)
Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7V3ivrc019903 for ; Tue, 30 Aug 2016 23:51:09 -0400
Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) by mx0a-001b2d01.pphosted.com with ESMTP id 255qkv84yf-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Aug 2016 23:51:08 -0400
Received: from localhost by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 31 Aug 2016 13:49:52 +1000
Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 31 Aug 2016 13:49:37 +1000
X-IBM-Helo: d23dlp02.au.ibm.com
X-IBM-MailFrom: sweeden@au1.ibm.com
X-IBM-RcptTo: scim@ietf.org
Received: from d23relay08.au.ibm.com (d23relay08.au.ibm.com [9.185.71.33]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id D3FAD2BB0054 for ; Wed, 31 Aug 2016 13:49:36 +1000 (EST)
Received: from d23av06.au.ibm.com (d23av06.au.ibm.com [9.190.235.151]) by d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7V3naKe6095352 for ; Wed, 31 Aug 2016 13:49:36 +1000
Received: from d23av06.au.ibm.com (localhost [127.0.0.1]) by d23av06.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u7V3naGo029450 for ; Wed, 31 Aug 2016 13:49:36 +1000
Received: from d50lp03.ny.us.ibm.com (d50lp03.pok.ibm.com [146.89.104.211]) by d23av06.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u7V3nYTQ029379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Aug 2016 13:49:36 +1000
Received: from localhost by d50lp03.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Tue, 30 Aug 2016 23:49:34 -0400
Received: from smtp.notes.na.collabserv.com (192.155.248.90) by d50lp03.ny.us.ibm.com (158.87.18.22) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128/128) Tue, 30 Aug 2016 23:49:31 -0400
X-IBM-Helo: smtp.notes.na.collabserv.com
X-IBM-MailFrom: sweeden@au1.ibm.com
X-IBM-RcptTo: scim@ietf.org
Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for  from ; Wed, 31 Aug 2016 03:49:30 -0000
Received: from us1a3-smtp04.a3.dal06.isc4sb.com (10.106.154.237) by smtp.notes.na.collabserv.com (10.106.227.141) with smtp.notes.na.collabserv.com ESMTP; Wed, 31 Aug 2016 03:49:28 -0000
X-IBM-Helo: us1a3-smtp04.a3.dal06.isc4sb.com
X-IBM-MailFrom: sweeden@au1.ibm.com
X-IBM-RcptTo: scim@ietf.org
Received: from us1a3-mail98.a3.dal06.isc4sb.com ([10.146.21.239]) by us1a3-smtp04.a3.dal06.isc4sb.com with ESMTP id 2016083103492873-2192 ; Wed, 31 Aug 2016 03:49:28 +0000 
MIME-Version: 1.0
To: scim@ietf.org
From: "Shane B Weeden" 
Date: Wed, 31 Aug 2016 13:37:58 +1000
X-KeepSent: 52511F99:324D9451-4A258020:0013B6C7; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1EXT SHF692 April 27, 2016
X-LLNOutbound: False
X-Disclaimed: 11251
X-TNEFEvaluated: 1
Content-type: multipart/alternative;  Boundary="0__=C5BB0AB3DF8030578f9e8a93df938690918cC5BB0AB3DF803057"
Content-Disposition: inline
x-cbid: 16083103-0044-0000-0000-000001D550B1
X-IBM-ISS-SpamDetectors: Score=0.423878; BY=0.000504; FL=0; FP=0; FZ=0; HX=0;  KW=0; PH=0; SC=0.423878; ST=0; TS=0; UL=0; ISC=
X-IBM-ISS-DetailInfo: BY=3.00005683; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000184; SDB=6.00751907; UDB=6.00355438; UTC=2016-08-31 03:49:29
x-cbparentid: 16083103-9718-0000-0000-000000BBD7E8
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
Message-Id: 
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-30_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608310049
Archived-At: 
Subject: [scim] question on SCIM query results
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 03:51:10 -0000

--0__=C5BB0AB3DF8030578f9e8a93df938690918cC5BB0AB3DF803057
Content-Transfer-Encoding: quoted-printable
Content-type: text/plain; charset=US-ASCII


If I perform a very basic SCIM user query without attributes or
excludedAttributes filters, such as:

GET /Users?filter=3D"username sw test"

Should the returned resources contain a meta attribute?

Regards,
Shane.

--0__=C5BB0AB3DF8030578f9e8a93df938690918cC5BB0AB3DF803057
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline


If I perform a very basic SCIM user query without attributes=
 or excludedAttributes filters, such as:

GET /Users?filter=3D"u=
sername sw test"

Should the returned resources contain a meta a=
ttribute?

Regards,
Shane.



--0__=C5BB0AB3DF8030578f9e8a93df938690918cC5BB0AB3DF803057--


From nobody Tue Aug 30 22:54:28 2016
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365B12D7DE for ; Tue, 30 Aug 2016 22:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level: 
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cPat3a7DdzYK for ; Tue, 30 Aug 2016 22:54:12 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 2321712D0F0 for ; Tue, 30 Aug 2016 22:54:11 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7V5s9NT023592 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 05:54:09 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7V5s9XC000485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 05:54:09 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u7V5s8V9000393; Wed, 31 Aug 2016 05:54:09 GMT
Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Aug 2016 22:54:08 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-C4A38593-196B-4E3C-A3FB-541CA768B076
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13G36)
In-Reply-To: 
Date: Tue, 30 Aug 2016 22:54:06 -0700
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: Shane B Weeden 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: scim@ietf.org
Subject: Re: [scim] question on SCIM query results
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 05:54:16 -0000

--Apple-Mail-C4A38593-196B-4E3C-A3FB-541CA768B076
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Yes  =20

You should get all attributes where returned is default or always.=20

Phil

> On Aug 30, 2016, at 8:37 PM, Shane B Weeden  wrote:
>=20
> If I perform a very basic SCIM user query without attributes or excludedAt=
tributes filters, such as:
>=20
> GET /Users?filter=3D"username sw test"
>=20
> Should the returned resources contain a meta attribute?
>=20
> Regards,
> Shane.
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

--Apple-Mail-C4A38593-196B-4E3C-A3FB-541CA768B076
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Yes   

You should get all attributes where returned is default or always. 

Phil

On Aug 30, 2016, at 8:37 PM, Shane B Weeden <sweeden@au1.ibm.com> wrote:

If I perform a very basic SCIM user query without attributes or excludedAttributes filters, such as:

GET /Users?filter="username sw test"

Should the returned resources contain a meta attribute?

Regards,
Shane.



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

--Apple-Mail-C4A38593-196B-4E3C-A3FB-541CA768B076--