Subject: [scim] How to signal when a query is not eligible for use with HTTP GET (due to PII/security)

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Apr 2014 10:56:40 -0700

In the current spec, we have created the POST profile so that searches with confidential data can be made without exposing confidential data in the URL (via GET).

I had a question from one of our developers about how does the client know when to use GET vs. POST?

a.  For all queries?
b.  Should an attribute have some metadata flagging it as not usable on GET?
c.  Should GET return a specific error when a query is to be repeated as a POST?

The concern with c. is that once done the data is exposed. In our internal group we discussed that this would likely happen the first time a client starts talking to a new endpoint — so either the deployer or a developer would see the error.  IOW, once a client knows an attribute is “confidential” it wouldn’t normally keep doing the same thing.

I’m not sure there is a good answer here.  Any other ideas?

Phil

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

---

From: Bill Mills <[email-masked]>
Date: Tue, 29 Apr 2014 12:55:13 -0700 (PDT)

I think if the site has concerns about this then they only support POST for queries and return a 405 for all GET to the query endpoint.  Trying to parse the data sent to determine guarantees you'll fail to protect the data properly.
On Tuesday, April 29, 2014 10:57 AM, Phil Hunt <[email-masked]> wrote:

a.  For all queries?

Phil

@independentid
[email-masked]

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Apr 2014 13:15:02 -0700

Bill,

Interesting simplification. However, the URL is still exposed even when the server returns a 405.

But as with the more complex approach, you’d think clients would switch to POST for future requests. 

I think this is mainly a security considerations issue.

Other than the obvious “it is restful to do GET”, why might a client *want* or *need* to do a GET?  Is it reasonable as Bill suggests that servers could drop GET in favour of POST search only?

Phil

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

---

From: Bill Mills <[email-masked]>
Date: Tue, 29 Apr 2014 14:27:33 -0700 (PDT)

Yeah, there's still the possibility of leaking with this, but it's less than when the client has to probe for which data elements might be bad.
On Tuesday, April 29, 2014 2:15 PM, Phil Hunt <[email-masked]> wrote:
 
Bill,

Phil

@independentid