Subject: [scim] Implementer Questions

From: Grahame Grieve <[email-masked]>
Date: Sat, 16 Aug 2014 09:26:57 +1000

hi

I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am
just adding SCIM support to my FHIR reference server - partly to allow
me to use SCIM for it's purpose in my server, and partly so we can
explore what is required to write up how to integrate SCIM into FHIR
(and therefore encourage users in health to adopt it - it's still over
the horizon for health, but not long now)

I have a few questions that the documentation doesn't really explain:

1. can you PUT after a DELETE to bring a user back to life?

2. When you do a PUT, the document says:

Attributes whose mutability is "readWrite", that are omitted from the
   request body, MAY be assumed to be not asserted by the client.  The
   service provider MAY assume any existing values are to be cleared or
   the service provider MAY assign a default value to the final resource
   representation.  Service providers MAY take into account whether a
   client has access to, or understands, all of the resource's
   attributes when deciding whether non-asserted attributes SHALL be
   removed or defaulted.  Clients that would like to override a server
   defaults, MAY specify "null" for a single-valued attribute or an
   empty array "[]" for a multi-valued attribute to clear all values.

I find this little obscure for multi-valued attributes. If the client
provides a single email address, then all the existing ones are
over-written? It would be nice if this were clear. Also, this doesn't
address the question of a extension schemas - I haven't found anywhere
about whether a server is allowed to accept extension schemas it
doesn't know about (or required to), but if it can/does, how does that
work with updates?

3. if the server exposes the same interface on multiple host names
(this is common), what happens to meta.location?

4. there's nothing like a namespace on the user name. If you're using
SCIM with OAuth, and auto-creating user accounts on the fly, where
would the OAuth user identity go? (The intent here is that you
autocreate the user resource, but then a user can edit the details
associated with the account after it is created)

5. Regarding query, it says "SCIM service SHOULD ignore any query
parameters they do not recognize" - the specification doesn't give
guidance about what to do if a single parameter in a value path or a
logical conjunction is not recognised (treat it as true or false or
ignore the whole group?). And there doesn't seem like a way for the
client to know what has been accepted or not? But later the
specification says "Providers MUST decline to filter results if the
specified filter operation is not recognized" - This doesn't seem
reliably consistent

6. I am mystified by the /ServiceProviderConfigs end-point. As far as
I can figure out, there is only ever one config, so do you have to
search for it? or does it have some kind of fixed identity that I have
missed?

thanks

-- 
-----
http://www.healthintersections.com.au /
[email-masked] / +61 411 867 065

---

From: Phil Hunt <[email-masked]>
Date: Sat, 16 Aug 2014 10:53:25 -0700

Grahame,

Thanks for your comments. Its always useful to say any issues around clarity as we are going through the final editorial revisions now.

Phil

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

> 1. can you PUT after a DELETE to bring a user back to life?
Per RFC2119 regarding keywords, the use of SHOULD is critical here under the definition of the DELETE operation.

In this case, my read of the draft is that a PUT after a DELETE, SHOULD NOT be possible.  This is because the identifier and any unique keys SHOULD be released. A delete is a delete. 

Note: this used to be a MUST. After some discussion in Toronto, we weakened compliance to SHOULD.  

If an implementer chooses not to follow the SHOULD language, it might be possible that this would work.

There has been some discussion on tombstoning, but the group decided to delay its definition (as far as I recall).

IMO, you are better to use “active” to deactivate an account and reactivate it for now.
> doesn't know about (or required to), but if it can/does, how does that
The meaning of PUT is an entire replace. 

A couple of considerations:
1. What happens if a client does a GET, changes one of the attributes client-side and then puts the object back with a PUT (kind of like a “bean”).
2. In order to be simple for the client, the server should be flexible in what it accepts. The rules indicate what the server will do when certain conditions arise around attribute mutability — e.g. can a client replace a read only attribute

For multi-valued attributes or complex attributes, the overall intent of PUT is still to replace the entire resource. If you want to replace specific values, you need to use the PATCH operation or have the client manipulate the values itself and provide the full set of values to replace.
> (this is common), what happens to meta.location?

I would defer to normal HTTP/1.1 rules on this.  In practice, the meta-location (and Location header) you return should be the one that you expect the client to use next time.
> 
> 4. there's nothing like a namespace on the user name.

I’m not sure what you mean here.  Yes, the userName is not associated with any particular use. I would have to defer to the original SCIM 1 authors on this decision.

> If you're using

SCIM like OAuth would have nothing to say about how you build this process much like OAuth doesn’t have anything to say about usernames.

In practice, it might be reasonable to have an authenticated UI component that has been authorized by oAuth based on its client credentials to perform registration of users that are anonymous to the client.  This would mean the SCIM POST contains an authorization header that has a token representing the UI client component.

In other cases, you might allow completely anonymous POST to the /Users endpoint to create a User resource.  I would proceed with caution as you want to be concerned about DoS attacks.

That said, once a User object is created in the service provider, it is not for SCIM to say what happens next. It could be that a provisioning workflow kicks in and things like email confirmations happen.  Many have commented that initially a new SCIM User does not have full entitlements or maybe even active status until the workflow for provisioning is done.  This is up to you to define.
> specified filter operation is not recognized" - This doesn't seem

This is tricky languages that most specifications run into. The objective is to allow future specifications to define new parameters while ensuring the older servers will still work in a predictable way.

In this case, filter is an optional parameter. A server may choose to ignore it. But if it chooses to support it, it must understand the entire parameter.  In other words, if the server supports filters, then all filters must be valid.  The server can’t partially understand a filter value. If the server doesn’t understand part of the parameter the whole operation must fail.  If the server doesn’t understand or support filters at all the server may ignore filters.

> search for it? or does it have some kind of fixed identity that I have
Yes, this one is an oddball. There is only one resource, but it does need its own end-point. Hence /ServiceProviderConfig.  We could allow /ServiceProviderConfig.scim  (or .json) to make it appear more like the single resource it is rather than look like a container (like /Users).

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

---

From: Grahame Grieve <[email-masked]>
Date: Sun, 17 Aug 2014 07:42:51 +1000

Thanks. Comments in line.

Grahame

> In this case, my read of the draft is that a PUT after a DELETE, SHOULD NOT be possible.  This is because the identifier and any unique keys SHOULD be released. A delete is a delete.

I don't see a SHOULD in the delete section.
(http://tools.ietf.org/html/draft-ietf-scim-api-09#section-3.4)
I guess this refers to the first must. in which case, well, ok, but
adding "including a PUT" would clarify

> For multi-valued attributes or complex attributes, the overall intent of PUT is still to replace the entire resource. If you want to replace specific values, you need to use the PATCH operation or…

I think that the mixed language confuses things. If it's an entire
replace, why the confusing language around attributes that are null or
not? just make the put a put and a use patch for patching. I think
that this mixed model is the worst of both worlds

> I would defer to normal HTTP/1.1 rules on this.  In practice, the meta-location (and Location header) you return should be the one that you expect the client to use next time.

well, I don't know what the normal rules are, since the meta is
*content* not header. I don't understand what it's presence is for
except to make this case confusing.

> SCIM like OAuth would have nothing to say about how you build this process much like OAuth doesn’t have anything to say about usernames.

but shouldn't something somewhere say something about this? I suppose
you'd put a URI representing the OAuth user identification in the
externalId. It just seems to me that given the scope of SCIM, this
combination will be very common - auto creating accounts persuant to
OAuth, and then exposing those accounts on an authenticated SCIM
interface so permissions etc can be managed. Shouldn't someone
somewhere say something about how a client might recognise the right
user account?

> This is tricky languages that most specifications run into. The objective is to allow future specifications to define new parameters while ensuring the older servers will still work in a predictabl…

well, ok, and I see I misread that.

> In this case, filter is an optional parameter. A server may choose to ignore it. But if it chooses to support it, it must understand the entire parameter.  In other words, if the server supports fi…

well, ok, but it makes future extensibility a problem

> Yes, this one is an oddball. There is only one resource, but it does need its own end-point. Hence /ServiceProviderConfig.  We could allow /ServiceProviderConfig.scim  (or .json) to make it appear…

if there's only one resource, can the spec assign a fixed identifier
to it so that it's easy to get it? how is that supposed to work - you
search for it using what parameter?

Grahame

---

From: Phil Hunt <[email-masked]>
Date: Sat, 16 Aug 2014 15:53:13 -0700

Graham,

Regarding delete, the text is:
>    Clients request resource removal via DELETE.  Service providers MAY
>    choose not to permanently delete the resource, but MUST return a 404
>    error code for all operations associated with the previously deleted
>    Id.  Service providers MUST also omit the resource from future query
>    results.  In addition the service provider SHOULD NOT consider the
>    deleted resource in conflict calculation.  For example if a User
>    resource is deleted, a CREATE request for a User resource with the
>    same userName as the previously deleted resource should not fail with
>    a 409 error due to userName conflict.

When a delete has occurred the resource MUST return a 404. Therefore an attempt to do a PUT, MUST return a 404.

What I was speaking to is the fact that it might actually work on some servers (see second part of paragraph), but only because the entry is being maintained in some “hidden” fashion keeping the identifier and userName “reserved".  How those people intend to resurrect the entry is not defined in a standard way.  

Phil

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

> that this mixed model is the worst of both worlds

I agree. Refinement is likely necessary. However the determine functionality was arrived at by consensus. if you wish to propose alternate text, I’m sure the group would consider it if it improves clarity. Before you do so, I invite you to read through the mail logs. There are quite a number of inter-related issues.
> except to make this case confusing.

There is a “location” header.  Meta.location is intended to be the same.

> somewhere say something about how a client might recognise the right

Speaking as an OAuth WG member, OAuth does NOT provide authentication information to clients. It provides authorization to clients to access a resource (in this case a SCIM SP). You’ll want OpenID Connect if you want ID Profile information to be passed to clients.

That said, we did add an “alias”  which is “/Me”.  A client performing a GET “/Me” will get the resource matching the currently authenticated “subject” as far as the SCIM resource server is concerned.  Note:  If there is no User, this might be an OAuth “Client” or other application credential.  This is why the alias is not GET “/Users/me”.

I agree, How you choose to integrate these is open to you (at present). OAuth is but one of many possible authorization model. Please keep in mind that the current charter only covers provisioning.  So scenarios like SCIM acting as a directory are not yet in scope (though as you say quite likely).
> well, ok, but it makes future extensibility a problem

How so?

---

From: Grahame Grieve <[email-masked]>
Date: Sun, 17 Aug 2014 22:53:12 +1000

> attempt to do a PUT, MUST return a 404.

Y. I guess in didn't think through the consequences of that sentence did I?

On Aug 16, 2014, at 2:42 PM, Grahame Grieve <
[email-masked]> wrote:

>> In this case, my read of the draft is that a PUT after a DELETE, SHOULD
> NOT be possible.  This is because the identifier and any unique keys SHOULD
> be released. A delete is a delete.

Heh. There's no such thing as true delete in healthcare. People feel very
strongly about that. So we in health would never say "a delete is a
delete". But for scim I don't have any requirements like that, and I'm fine
with it

> I agree. Refinement is likely necessary. However the determine
> functionality was arrived at by consensus. if you wish to propose alternate
> text, I’m sure the group would consider it if it improves clarity. Before
> you do so, I invite you to read through the mail logs.

I said to myself when I started this that I wasn't going to argue. I don't
have time to give it justice. So I'll leave this

 I don't understand what it's presence is for
> There is a “location” header.  Meta.location is intended to be the same.

Oh. And the definition even says that. Oops. So why us it there if it's in
the header? Most similar specs will simply mandate that there be a location
header (ah, here I go again. But some explanation of why it's duplicated
would be good)

>>
> >> SCIM like OAuth would have nothing to say about how you build this
> process much like OAuth doesn’t have anything to say about usernames.
> >
> Speaking as an OAuth WG member, OAuth does NOT provide authentication
> information to clients.

Well, ok, it doesn't. There is, though, almost always some introspection
endpoint that does openid connect based (or some derivation) user id.
Perhaps I phrased the question badly, but still: who's business would it be
to describe how they should work together?

> > well, ok, but it makes future extensibility a problem

oh no, you'll go for v3 then? I guess that would work.

> > search for it using what parameter?

no answer on this one?

Grahame