scim notes

1.0 Issue squashing

#50 Bjoern Aannestad

Filter semantics for complex plural attributes

SCIM filters can't cope with searches on multi-valued attributes (e.g. email address is primary and contains "@example.com"). Therefore SCIM filters' syntx needs corresponding enhancement.

Options to consider:
Filter dot notation (includes possible need for . AND .. operators)
Use a filter operator such as INSTANCE()
Use a back-reference; e.g. use "%1" notation to specify that multiple uses of an attribute must refer to the same instance of the attribute
Use a JSON filter structure

Additional suggestion: should the LDAP query language be considered?
Morteza Ansari: LDAP filter is too simple to handle the multi-valued attribute cases being described her

Over-all, comments seemed to centre around options 1, 2 and 3, with 4 tending to be lower in popularity.
A "cleaned-up" option 1 might satisfy most of those present.

CONSENSUS: Bjoern to revise option 1 based on in-room comments, annotate the Issue ticket and close it.

#46  Kelly Grizzle
  
Clarify error responses and allow non-HTTP error codes

KG - 5 guidelines from current 'good practice' guidelines

ACTION: KG to write up appropriate text and add to the ticket.

#10 #35 #47 Phil Hunt
SCIM Attributes

Notes for Phil 

1 - Policy is applied separately from the processing that may chose to further restrict what gets returned. (In response to Bjoern's question about whether policy considerations [e.g. user does not have rights to retrieve a given attribute] over-ride DEFAULT settings or not.  

2 - #47 change "indexed" to "indexes" [Modulo comment from MA: there are other considerations which affect the 'legitimacy of a given query, and whether the appropriate response from the server is to throw an error]

Singular Attribute Defaults:
Retrieval of the "password" attribute via this mechanism is potentially contentious. (On the other hand, per Phil H, that imposes a requirement for a separate (authN/security) protocol just for passwords. And an organisation might legitimately be using SCIM as a privileged protocol therefore entitled to retrieve password as an attribute).

ACTION: Carefully worded guidance needed in the Security Considerations section

ACTION: "Attributes" category should be split into normative and non-normative sections [ID, pw and some metadata -> normative]


KG: extensive comment on defaults...

KG: Service provider config; a slightly odd use-case for a filtered query mechanism. Question whether this complexity is needed.

ACTION PH/KG to follow up offline.

HUM on #10: rough consensus for suggested approach. Bjoern to write up his concern.

HUM on #35: consensus for the suggested approach.

PH to close tickets with proposed text.

HUM on #47: weak consensus in favour, but sufficient dissent to require further work. Ticket to remain open.

ACTION: LJ to move draft SCIM use-case document to WGLC: http://tools.ietf.org/wg/scim/draft-ietf-scim-use-cases/


ACTION: Call for reviews of Mark Wahl's JIT provisioning draft: http://tools.ietf.org/id/draft-wahl-scim-jit-profile-01.txt
"Volunteers": Kelly G, Phil H, Robin W, John B