Subject: [scim] Agenda request for sept 18

From: Phil Hunt <[email-masked]>
Date: Mon, 9 Sep 2013 14:07:54 -0700

* Sensitivity/index/returnability (see update on Item 10)

* Passwords - Can passwords be validated? Regarding validating passwords, I understand some want to keep this out of scope of SCIM. 

Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc?

Phil

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

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 10 Sep 2013 13:45:15 +0000

Regarding passwords, I would say that this is outside of the scope of SCIM and should be handled by a complimentary protocol (eg - OpenID Connect).  The charter explicitly excludes authn:

The group considers the following out of scope for this group:
Defining new authentication schemes

To me, password validation (even with an authenticated SCIM request) seems out of scope.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, September 09, 2013 4:08 PM
To: [email-masked] WG
Subject: [scim] Agenda request for sept 18

Phil

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

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Sep 2013 07:53:31 -0700

I am not referring to authen mechanisms in scim. I am referring to password management only. 

Phil

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 10 Sep 2013 15:23:14 +0000

What features do you think fall under password management?

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 9:54 AM
To: Kelly Grizzle
Cc: [email-masked] WG
Subject: Re: [scim] Agenda request for sept 18

Phil

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Sep 2013 10:12:49 -0700

There seems to be confusion between authentication "mechanism" and "data".  I don't believe management of authentication data is out of scope.  Quite the contrary, it is a major reason why clients do provisioning.

An authentication mechanism would be an actual function like "bind" that is part of the protocol. This is not needed since SCIM is just a REST API so the web server platform picks this up.  The confusion may come from LDAP, which in fact is its own access protocol and thus must have a mechanism of its own. In contrast, SCIM sits on HTTP.  Hence, then authentication mechanism should be out of scope.

A password by itself is just data (well data with security concerns). It seems reasonable for a trusted client to be able to test a value just as for any other attribute. It may be testing that value as part of a change password service it is implementing (as an example).  Such a client may also want to maintain and evaluate other data like password policy and password history. 

The reason for discussing passwords on the call is because of the possible special restriction on password attributes (can't be queried). 

I would like to leave it open for the group to either include password management in the base drafts, or more importantly write an extension draft in the future.  Either is fine by me. However, time is short for agreement since many are either in production or are rapidly headed that way.

It seems like a good time to discuss the issue now.

Phil

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

---

From: Bjorn Aannestad <[email-masked]>
Date: Tue, 10 Sep 2013 14:51:53 -0500

+1

-Bjorn

---

From: Mark Diodati <[email-masked]>
Date: Tue, 10 Sep 2013 15:17:35 -0500

Hi All,

It would be nice to see a tightly scoped, limited authentication
capability, for password only (today). The consumer could POST with
uname/password combination to a common authentication endpoint, then
receive a response. I suppose that introduces a requirement for uniqueness
on the attribute that functions as the uname. There is precedence for
adding a bare-bones authentication method to a (primarily) provisioning
protocol.

Perhaps with the presence of growing long-term demand for authentication
functionality within SCIM, we could explore other authentication options
like <shortOnDetails OIDC ID token</shortOnDetails>.

Mark

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 12:13 PM
To: Kelly Grizzle
Cc: [email-masked] WG
Subject: Re: [scim] Agenda request for sept 18

There seems to be confusion between authentication "mechanism" and "data".
I don't believe management of authentication data is out of scope.  Quite
the contrary, it is a major reason why clients do provisioning.

An authentication mechanism would be an actual function like "bind" that
is part of the protocol. This is not needed since SCIM is just a REST API
so the web server platform picks this up.  The confusion may come from
LDAP, which in fact is its own access protocol and thus must have a
mechanism of its own. In contrast, SCIM sits on HTTP.  Hence, then
authentication mechanism should be out of scope.

A password by itself is just data (well data with security concerns). It
seems reasonable for a trusted client to be able to test a value just as
for any other attribute. It may be testing that value as part of a change
password service it is implementing (as an example).  Such a client may
also want to maintain and evaluate other data like password policy and
password history.

The reason for discussing passwords on the call is because of the possible
special restriction on password attributes (can't be queried).

I would like to leave it open for the group to either include password
management in the base drafts, or more importantly write an extension
draft in the future.  Either is fine by me. However, time is short for
agreement since many are either in production or are rapidly headed that
way.

Phil

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

On 2013-09-10, at 8:23 AM, Kelly Grizzle <[email-masked]>
wrote:

>> Regarding passwords, I would say that this is outside of the scope of
SCIM and should be handled by a complimentary protocol (eg - OpenID
Connect).  The charter explicitly excludes authn:
>> * Passwords - Can passwords be validated? Regarding validating
passwords, I understand some want to keep this out of scope of SCIM.

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 10 Sep 2013 20:32:48 +0000

I totally agree with the need to manage passwords.  Issue #14 (http://trac.tools.ietf.org/wg/scim/trac/ticket/14) is geared toward some enhancements around this.

And I'm starting to see your point on the ability to test a password.  Like Mark said, if we do something here, it feels like it should be very tightly scoped.  What about something like doing a POST-based search to the specific user that you want to test:

    POST /v1/Users/12345/.search
    filter=password eq "s3cret!"

This specific pattern could be extended to provide slightly more information in the response to indicate the results (eg - expired password, locked account, etc...).

--Kelly

-----Original Message-----
From: Mark Diodati [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 3:18 PM
To: Phil Hunt; Kelly Grizzle
Cc: [email-masked]
Subject: RE: [scim] Agenda request for sept 18

Hi All,

It would be nice to see a tightly scoped, limited authentication capability, for password only (today). The consumer could POST with uname/password combination to a common authentication endpoint, then receive a response. I suppose that introduces a requirement for uniqueness on the attribute that functions as the uname. There is precedence for adding a bare-bones authentication method to a (primarily) provisioning protocol.

Perhaps with the presence of growing long-term demand for authentication functionality within SCIM, we could explore other authentication options like <shortOnDetails OIDC ID token</shortOnDetails>.

Mark

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 12:13 PM
To: Kelly Grizzle
Cc: [email-masked] WG
Subject: Re: [scim] Agenda request for sept 18

There seems to be confusion between authentication "mechanism" and "data".
I don't believe management of authentication data is out of scope.  Quite the contrary, it is a major reason why clients do provisioning.

Phil

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

SCIM and should be handled by a complimentary protocol (eg - OpenID Connect).  The charter explicitly excludes authn:
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of
Phil Hunt

---

From: Leif Johansson <[email-masked]>
Date: Tue, 10 Sep 2013 22:42:00 +0200

> Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc?
Looks like we're getting this done on the list instead.

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 13 Sep 2013 16:08:18 +0000

I would like to add a topic to next weeks call, and that would be about a 10 min discussion of a interop at IETF 88 that Mark Wahl will lead.