Subject: [scim] Call today?

From: Phil Hunt <[email-masked]>
Date: Wed, 5 Feb 2014 09:01:30 -0800

Details?

Phil

---

From: Bjorn Aannestad <[email-masked]>
Date: Wed, 05 Feb 2014 12:16:24 -0600

It might be here:
https://go.webex.com/go/j.php?ED=153193777&UID=-1&RT=MiM0

11 Pacific.

-Bjorn

On 2014-02-05 11:01 AM, Phil Hunt wrote:
> Details?
>
> Phil
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Wed, 5 Feb 2014 10:36:38 -0800

Attached is the current 03 in progress diff against the published 02 draft.  I have also attached the current task items worksheet.

Some possible items for today's discussion….

1.  removal of readOnly meta-attribute (replaced by mutability)
2.  indexed -- do we want to go ahead with this?  What was the consensus?
3.  update on redirects

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 5 Feb 2014 19:39:29 +0100

> 5 feb 2014 kl. 18:01 skrev Phil Hunt <[email-masked]>:
> 
> Details?
> 

its next week right?

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 12 Feb 2014 01:14:39 +0000

Correct, the next meeting is Wed. Fed. 12th at 11am Pacific time.  Meeting
info is here:

To invite others to join, copy and paste everything below into your
invitation. 
-------------------------------------------------------
Meeting information
-------------------------------------------------------
Topic: SCIM WG interim
Date: Every Wednesday, from Wednesday, August 21, 2013 to no end date
Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 340 844 711
Meeting Password: (This meeting does not require a password.)

-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to https://go.webex.com/go/j.php?ED=153193777&UID=483472947&RT=MiM0

-------------------------------------------------------
Audio conference information
-------------------------------------------------------
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll free: 1-855-797-9485
US Toll: +1-415-655-0002
Global call-in numbers:
https://go.webex.com/go/globalcallin.php?serviceType=MC&ED=153193777&tollFr
ee=1 
Toll-free dialing restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:340 844 711

-------------------------------------------------------
For assistance 
-------------------------------------------------------
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://go.webex.com/go/j.php?ED=153193777&UID=483472947&ICS=MS&LD=1&RD=2&S
T=1&SHA2=AAAAAXFmPcl25G51pP-VAnTUIPjOJqt0XNEPVKSSFdjwCd-F

To check whether you have the appropriate players installed for UCF
(Universal Communications Format) rich media files, go to
https://go.webex.com/go/systemdiagnosis.php.

http://www.webex.com <http://www.webex.com/>

CCM:+14156550002x340844711#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
and any documents and other materials exchanged or viewed during the
session to be recorded. You should inform all meeting attendees prior to
recording if you intend to record the meeting. Please note that any such
recordings may be subject to discovery in the event of litigation.

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 12 Feb 2014 19:03:43 +0000

The link the meeting is not working for me.  It is showing a meeting on the 19th.

Morteza, can you send the correct link?

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Tuesday, February 11, 2014 7:15 PM
To: Leif Johansson; Phil Hunt
Cc: [email-masked] WG
Subject: Re: [scim] Call today?

Correct, the next meeting is Wed. Fed. 12th at 11am Pacific time.  Meeting info is here:

To invite others to join, copy and paste everything below into your invitation. 
-------------------------------------------------------
Meeting information
-------------------------------------------------------
Topic: SCIM WG interim
Date: Every Wednesday, from Wednesday, August 21, 2013 to no end date
Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 340 844 711 Meeting Password: (This meeting does not require a password.)

To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.

Access code:340 844 711

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:

To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://go.webex.com/go/systemdiagnosis.php.

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 12 Feb 2014 11:05:11 -0800

Looks to be fixed now.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 12 Feb 2014 19:06:03 +0000

It should be working now.  Not sure what happened but will set up a new
one for next meeting to ensure this is fixed.

Cheers,
Morteza

On 2/12/14 11:03 AM, "Kelly Grizzle" <[email-masked]> wrote:

>Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting
>Number: 340 844 711 Meeting Password: (This meeting does not require a
>password.)
>

---

From: Bill Mills <[email-masked]>
Date: Wed, 12 Feb 2014 12:14:22 -0800 (PST)

My action item from the call:  Propose language around immutability and PUT.

I don't know whether this goes into the definition of immutability or PUT, probably PUT:

"PUT expects the entire object to be present, if the schema includes elements with immutable or ReadOnly elements then the object submitted with a PUT MUST include all existing immutable and ReadOnly data.  The server MUST reject the PUT and return an error if the submitted data for  immutable or ReadOnly elemets do not match exactly."

On Wednesday, February 12, 2014 11:06 AM, Morteza Ansari (moransar) <[email-masked]> wrote:

Cheers,
Morteza

---

From: Phil Hunt <[email-masked]>
Date: Wed, 12 Feb 2014 13:19:19 -0800

Bill,

Thanks for the proposal.

Looks like we also didn't consider readOnly and writeOnly attributes such as passwords.  

Let me think this aft and I'll put a quick proposal together.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Wed, 12 Feb 2014 14:18:25 -0800 (PST)

Yeah, WriteOnly needs thought, we don't want to end up with PUT transactions deleting passwords.  Passwords perhaps might need a "required" attribute which means that a PUT that doesn't include it would fail.

On Wednesday, February 12, 2014 1:19 PM, Phil Hunt <[email-masked]> wrote:
 
Bill,

Thanks for the proposal.

Phil

@independentid
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Wed, 12 Feb 2014 15:17:33 -0800

Yes.  I was just thinking that.  "required" means that the client MUST provide it. So a SP could say the password is required.

How about the following table of impacts based on mutability of attributes in a PUT operation:

When submitting attributes via the PUT request, attribute "mutability" will have the following impacts:
readWrite, writeOnly - Any values provided replace the existing values. Omitting the attribute or specific values means the attribute or values are to be removed.
immutable - Any values provided MUST match the existing values. An omission of the attribute will not remove the existing value(s).
readOnly - Any values provided (e.g. meta.resourceType) will be ignored.

If an attribute is "required", the client MUST specify the attribute in a PUT request. 

Does this work?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Wed, 12 Feb 2014 15:36:56 -0800

Makes sense.  Need to specify the failure for omitted required attributes and attempts to change immutable things.

-bill

--------------------------------
William J. Mills
"Paranoid" Yahoo!

On Wednesday, February 12, 2014 3:17 PM, Phil Hunt <[email-masked]> wrote:

When submitting attributes via the PUT request, attribute "mutability" will have the following impacts:
	* readWrite, writeOnly - Any values provided replace the existing values. Omitting the attribute or specific values means the attribute or values are to be removed.
	* immutable - Any values provided MUST match the existing values. An omission of the attribute will not remove the existing value(s).
	* readOnly - Any values provided (e.g. meta.resourceType) will be ignored.

Does this work?

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 12 Feb 2014 15:54:52 -0800

Sorry for all the back and forth going on.  I think I have got it with error codes and a decent amount of flexibility.  Here is the proposed text:

3.3.1.  Modifying with PUT

   PUT performs a full update.  Clients MAY retrieve the entire resource
   in advance, add the desired modifications and use HTTP PUT which will
   overwrite all previously stored data.  Since the PUT request performs
   a full update, clients MAY send attributes of the retrieved resource
   and the service provider MUST process according to attribute
   mutability as follows:

   readWrite, writeOnly  Any values provided SHALL replace the existing
      attribute values.  Omitting the attribute or specific values means
      the attribute or specific value SHALL be removed;

   immutable  If values are provided, they MUST match existing data or
      an error is returned.  If the service provider has no existing
      values, a new value(s) MAY be specified; and,

   readOnly  Any values provided (e.g.  meta.resourceType) SHALL be
      ignored.

   If an attribute is "required", the client MUST specify the attribute
   in the PUT request.

   If a value provided for an immutable attribute with an existing value
   is NOT matched, the server SHALL respond with an HTTP response code
   of 400 and an apprpriate human readable message indicating an attempt
   to change an immutable attribute.

   Unless otherwise specified a successful PUT operation returns a 200
   OK response code and the entire resource within the response body,
   enabling the client to correlate the client's and Provider's views of
   the updated resource.  Example:

I admit, the wording could be better. But let's get the draft in tonight. 

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Wed, 12 Feb 2014 16:01:45 -0800

Small change:

immutable  If values are provided for elements already set in the object 
they MUST match existing data or
      an error is returned.  If the service provider has no existing
      values, a new value(s) MAY be specified; and,
 
-bill

On Wednesday, February 12, 2014 3:55 PM, Phil Hunt <[email-masked]> wrote:

3.3.1.  Modifying with PUT PUT performs a full update.  Clients MAY retrieve the entire resource in advance, add the desired modifications and use HTTP PUT which will overwrite all previously stored data.  Since the PUT request performs a full update, clients MAY send attributes of the retrieved resource and the service provider MUST process according to attribute mutability as follows: readWrite, writeOnly  Any values provided SHALL replace the existing attribute values.  Omitting the attribute or specific values means the attribute or specific value SHALL be removed; immutable  If values are provided, they MUST match existing data or an error is returned.  If the service provider has no existing values, a new value(s) MAY be specified; and, readOnly  Any values provided (e.g.  meta.resourceType) SHALL be ignored. If an attribute is "required", the client MUST specify the attribute in the PUT request. If a value provided for an immutable attribute with
 an existing value is NOT matched, the server SHALL respond with an HTTP response code of 400 and an apprpriate human readable message indicating an attempt to change an immutable attribute. Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire resource within the response body, enabling the client to correlate the client's and Provider's views of the updated resource.  Example: 

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 12 Feb 2014 16:10:22 -0800

:-)

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Erik Wahlström <[email-masked]>
Date: Fri, 14 Feb 2014 11:45:11 +0000

I’ve been giving it some thoughts afterwards and I don’t think this plays nice with passwords.

This means that we must always send the password in all PUT requests when just updating a user and passwords should be sent as little as possible over the wire.

We also have scenarios where we don’t always know the password, but we still know information about a user that we want to update at a service provider. For example if a authentication service provisions the username and the password, but some other, attribute server provisions other types of information about a user. This means that backend systems have to send passwords around to be able to always send them.

Another example could be a server product that provisions users to a service provider and to an internal AD and also stores info about the users in there own system, but don’t store the passwords. That means that they don’t have knowledge about the clear text password anymore, it’s only in AD, and it can’t update user information at a SCIM service provider.

I would prefer to just ignore attributes that’s not set and use PATCH if you would like to delete certain attributes. Just as it was before. In the early days, pre-ietf versions of documents, we also had a password endpoint that was later removed.

/ Erik

On 13 Feb 2014, at 01:10, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

:-)

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2014-02-12, at 4:01 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

Small change:

-bill

On Wednesday, February 12, 2014 3:55 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Sorry for all the back and forth going on.  I think I have got it with error codes and a decent amount of flexibility.  Here is the proposed text:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2014-02-12, at 3:36 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

-bill

On Wednesday, February 12, 2014 3:17 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Yes.  I was just thinking that.  "required" means that the client MUST provide it. So a SP could say the password is required.

Does this work?

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2014-02-12, at 2:18 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Wednesday, February 12, 2014 1:19 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Bill,

Thanks for the proposal.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2014-02-12, at 12:14 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Wednesday, February 12, 2014 11:06 AM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
It should be working now.  Not sure what happened but will set up a new
one for next meeting to ensure this is fixed.

Cheers,
Morteza

On 2/12/14 11:03 AM, "Kelly Grizzle" <[email-masked]<mailto:[email-masked]>> wrote:

>From: scim [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Morteza Ansari
>(moransar)
>Cc: [email-masked]<mailto:[email-masked]> WG
>http://www.webex.com <http://www.webex.com/> <http://www.webex.com/>
>
>On 2/5/14 10:39 AM, "Leif Johansson" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>
>>> 5 feb 2014 kl. 18:01 skrev Phil Hunt <[email-masked]<mailto:[email-masked]>>:
>>>
>>> Details?
>>>
>>
>>its next week right?
>>
>>> Phil
>>> [email-masked]<mailto:[email-masked]>
>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

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

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

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

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

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

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

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

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Feb 2014 13:36:18 +0100

On 2014-02-14 12:45, Erik Wahlström wrote:
> ...
> I would prefer to just ignore attributes that’s not set and use PATCH if
> you would like to delete certain attributes. Just as it was before. In
> the early days, pre-ietf versions of documents, we also had a password
> endpoint that was later removed.
> ...

PUT is not for partial updates. So if you don't want full updates, why 
don't you use PATCH right away?

Best regards, Julian

---

From: Erik Wahlström <[email-masked]>
Date: Fri, 14 Feb 2014 12:57:05 +0000

A very good point. Thanks :)
/ Erik

On 14 Feb 2014, at 13:36, Julian Reschke <[email-masked]> wrote:

> PUT is not for partial updates. So if you don't want full updates, why don't you use PATCH right away?
> 
> Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Fri, 14 Feb 2014 08:55:28 -0800

The trick here is to have good definitions on what immutability and writeOnly means in the context of PUT so that the action remains as much as possible a record swap.  Does the record "id" need to be provided?  Does the password need to be provided?  Can the client update record meta data?

There is some cause for discussion to clarify that a missing writeOnly attribute does not necessarily clear the value in the SP. But that means that clients can't clear passwords (would they ever want to do this?).   What if the writeOnly attribute was a security question or credit card?  Does it make sense for any future writeOnly attribute, or is this issue specific to passwords?  [ BTW This is just clearly another reason to kill passwords  :-) ]

I think the current spec is pretty good now. It can handle two different policies by the service provider.

A. The SP could set the password attribute to mutability=immutable and returned=never to create the effect of not requiring the client to know the password on a PUT. However, this means that the client could never update the password once set.

B. (the default) If a password is returned=never and mutability=writeOnly, then the effect will be that a PUT will clear the password if not provided.  Note:  a service provider could simply set a policy to ignore the value on PUT anyway.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Fri, 14 Feb 2014 09:07:43 -0800 (PST)

I suspect PUT is likely to be rarely used, only in case of a full sync needed.

On Friday, February 14, 2014 8:55 AM, Phil Hunt <[email-masked]> wrote:

Phil

@independentid
www.independentid.com
[email-masked]