scim minutes The working group was approved recently, so the agenda is fairly light. agenda bashing/remote participation details chairs' intro to the working groups ----------------------------------- the charter states that as input to the wg we're looking at a set of documents (scim 1.1). Published as drafts in i-d repository. how many unfamiliar with IETF (~15 hands)? of those, how many contributing to wg? (4 hands). the only thing the wg will be asked today is whether or not to adopt wg documents. [discussion of document adoption process, editor role, etc.] scim 1.1 overview and document status ------------------------------------- what's the problem? how do I keep my organization's users in sync with a given service, and how do I manage groups. scim client sits between organization directory and services. scim is a standard that defines schema and protocol for identity management. schema has representations of users and groups at core. protocol is restful, synchronous. Hannes: what does 'simple' mean? ans: provides a basic set of core functionality that addresses most use cases and is extensible. clarification: slim core spec with extensibility? ans: yes. Phil Hunt: goes back to REST - easy for the developer to deal with, should be intuitive. igor: there shouldn't be reason to question why a feature is there: that's "simple" history ... Dave Crocker: even the top level of getting started seemed like a deep dive. Didn't give a concise of summary of the solution statement, that all this detail is going to fit into. Answer: 10,000-foot view: there's an authoritatvie source for who you are (AD, other directory). Also have a user store. Federation is one way to solve it (single user store), scim solves the problem of taking user informaton from one system and install it in other systems schema: models for user and group. represented in json and xml (xml is optional). schema is extensible - both extending existing resources and defining new ones. Hannes said having two representations is inherently not simple. ans: I agree, but some implementors needed xml. a resource is a bag of attributes, name-spaced. attributes can be simple or complex, single-valued or multi-valued. name spacing through extension urns. Hannes raised other possibilities for namespace collision avoidance; Leif suggested we circle around back to this later. protocol: search and bulk are optional, simple stuff (crud, discovery) is mandatory mandatory: POST (create) GET PUT (update) DELETE. PATCH (update)and GET (search)are optional. discovery: GET /Schemas, GET /ServiceProviderConfig. q: why is update post and not put? a: pretty standard rest stuff. q: why should server do pagination? a: query parameters are optional, so you can do it client-side if you prefer. q: raises consistency problems. a: went with index-based pagination because it's easiest for some service providers. probably something we want to look at for 2.0. Leif: could you drop an email to the list about this? I really want us to capture this. q: having a stateful cursor would violate principles of RESTfulness. patch allows partial updates to resources. bulk allows performing many operations at once. both patch and bulk are optional. xml schema: xml xsd. maps to model we discussed beofre: core, resource/user/group, etc. security considerations: tls mti. standard http considerations apply. authentication is discoverable, oauth bearer token recommended. http basic auth is commonly implemented for interopreability. Stephen Farrell: when would you not want to run this over TLS? Ans: never. regarding caching: if this is over tls there's nothing to cache. Klaas: might not want to run over tls in a data center: ans: no, there are internal threats. Klaas: there are other ways to secure transport. What does "standard http considerations apply" mean? a: don't know, just copied slide. extended discussion of whether or not to require tls transport. Paul proposed ADs make a general statement about the use of TLS in apps area. Huilan Lu: do you really intend to ship passwords across the wire? a: this is never going to be retrieved, but it's needed when you provision accounts. Klaas: resources are opaque, which means you've got interop challenges. are you going to define profiles for typical use cases? a: we're going to have those discussions in 2.0. bindings: ldap (inetorgperson), saml, openid connect targeting allows single scim server to proxy scim request to a target system. 1.1 release: mainly clarifications and error fixes - no new functionality. will serve as starting point for working group. the owf community has agreed to move specs here. what's next: see charter for milestones. discussion of role/position of use cases. scim wg discussion ------------------ Phil Hunt raised a bunch of issues on the list. Had an informal discussion of the more complex ones; will send outcomes to list. . should directories evolve to support scim? Also, directory vendors getting requests for rest interfaces. Will scim be the next *directory* interface? . things impacting path uris: tenancy, targeting, "users" is too general, object types ay expand, ability to query for any object under / . the current search is under 'get' only - security concerns. ability to query using post? . rest "minimum" profile . add and replace - why not combine in put? minor difference is resource identifier . why not rework post to accommodate query and bulk? What's classic REST? Open mike --------- Jon Bradley: PUT and POST are not the same. we should probably try to fix the semantics rather than bend them. keep the rest semantics clear. Kent Watson: idempotence. Tony Nadalin: agree on resource type. shouldn't be in the uri. Looking at spec, don't see how to do multitenancy correctly with the urn path that's in there. Okay place to start but shouldn't rush to put out 1.1 lest people adhere to that. Prateek Mishra: tring to relate this to graph APIs. is this that a goal of this effort? Kelly: there are a lot and they're all different. the hope with scim was to bring some consolidation. whter a vendor uses it in addition or instead of is up to them. scim is optimized where there's a service provider who controls a bunch of identities, which is different (privacy models, etc.) from graph apis. Tony Nadalin: multitenancy raises other issues Paul Hoffman: let's go back to the s-word. axe xml, go back in your spec and see where you made xml-isms possible, then delete those. which brings up the topic of extensions ... Extensions become required, you lose simplicity really quickly. Also, stick with REST. Some optimizations will mess up REST-experienced developers (and that's not 'simple'). Also, authenticating users via public key is increasingly common - support that. Phil Hunt: do want to underline that major issue is that the ability to query without using filters on url is a major item we have to address, otherwise it will be a no-go. other items are stylistic. Agree on xml/json thing. Leif: would anybody like to stand up in defense of xml? many hands support going away, nobody supports keeping it, one person needs to think about it. Hannes: account provisioning, whether user name has a password. differnet administrative domains have different policies, so it doesn't work. have you run into that problem? kelly: yes. but we need a way to manage those passwords through scim. Leif: a couple of questions 1) who here has read drafts. Lots, including non-contributors 2) who would be in favor of adopting draft-scim-api and draft-scim-schema? Lots, nobody opposed, a few need more info. (Tony: adoption doesn't mean that the documents can't be significantly changed. Leif: right - adotping means moving change control to the working group, through wg consensus) wg seems comfortable adopting these. Also have to choose editors. There's a long list of authors, and there's an implied understanding that the same people will continue, but that's not always appropriate. We're going to have a substantial set of changes and the person editing will manage those changes rather than being an actor/advocate. 3) is there anybody not among current authors who'd like to help edit? (several) 4) need volunteers for use case. three or four - see Leif after meeting.