Subject: [scim] Adding a predefined userId - "me"

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 00:40:30 +0530

With the current spec - to get the details of a specific user we use the
following...

 GET /Users/2819c223-7f76-453a-919d-413861904646
 Host: example.com
 Accept: application/json
 Authorization: Bearer h480djs93hd8

How about having a pre-defined userid - which will provide back the logged
in users info.

 GET /Users/me
 Host: example.com
 Accept: application/json
 Authorization: Bearer h480djs93hd8

In the above case - the information about the user corresponding to the
provided Bearer token will be returned back. This would be similar to
Facebook's Graph API.

Appreciate your thoughts/suggestions...

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: Dale Olds <[email-masked]>
Date: Tue, 05 Feb 2013 13:09:06 -0800

I don't think it would be a good idea to have special userids for such a 
purpose, but I do see this as related to a larger issue with SCIM: only 
specifying an object by type and ID in the path makes the protocol 
chatty and access control more difficult.

In our implementation, we have had great difficulties in settling on an 
intuitive access control policy that allows applications to manage users 
and groups by name via SCIM. So, while I agree with these design goals 
for SCIM:

1) the only immutable identifier for a resource is an ID assigned by the 
server
2) access control policy and enforcement is outside of scope for SCIM 
(except, of course, for defining the groups attribute on a user as 
read-only :-) )

I am also interested in future discussion to allow an object to be 
updated without knowing the type and resource ID in advance.

We solved your particular use case by using the /user_info endpoint from 
OpenID Connect, and since I see you are using bearer tokens, you might 
look at that as well.

--Dale

On 02/05/2013 11:10 AM, Prabath Siriwardena wrote:
> With the current spec - to get the details of a specific user we use 
> the following...
>
>  Host: example.com <http://example.com>
>  Accept: application/json
> How about having a pre-defined userid - which will provide back the 
> logged in users info.
>
>  GET /Users/me
>  Host: example.com <http://example.com>
>  Accept: application/json
> In the above case - the information about the user corresponding to 
> the provided Bearer token will be returned back. This would be similar 
> to Facebook's Graph API.
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 02:39:41 +0530

Yes of course this is solved in OpenID Connect..  While writing [1] I
thought SCIM would also adress this concern to some extent by standardizing
this..

[1]:
http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 2:39 AM, Dale Olds <[email-masked]> wrote:

> specifying an object by type and ID in the path makes the protocol chatty
> and access control more difficult.
>
> and groups by name via SCIM. So, while I agree with these design goals for
> SCIM:
>
> I am also interested in future discussion to allow an object to be updated
> without knowing the type and resource ID in advance.
>
> OpenID Connect, and since I see you are using bearer tokens, you might look
> at that as well.
>
> --Dale
>
>>  GET /Users/2819c223-7f76-453a-**919d-413861904646
>> ______________________________**_________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/scim<https://www.ietf.org/mailman/listinfo/scim>
>>
>
> ______________________________**_________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/scim<https://www.ietf.org/mailman/listinfo/scim>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Phil Hunt <[email-masked]>
Date: Tue, 5 Feb 2013 13:32:50 -0800

There is also the issue of what me or "self" points to given all of the OAuth scenarios.  Is it the resource owner, the client_id, what is meant? What happens with a client acting on its own authority -- self means the client?

Phil

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

On 2013-02-05, at 1:09 PM, Dale Olds wrote:

> I don't think it would be a good idea to have special userids for such a purpose, but I do see this as related to a larger issue with SCIM: only specifying an object by type and ID in the path makes the protocol chatty and access control more difficult.
> 
> In our implementation, we have had great difficulties in settling on an intuitive access control policy that allows applications to manage users and groups by name via SCIM. So, while I agree with these design goals for SCIM:
> 
> 1) the only immutable identifier for a resource is an ID assigned by the server
> 2) access control policy and enforcement is outside of scope for SCIM (except, of course, for defining the groups attribute on a user as read-only :-) )
> 
> I am also interested in future discussion to allow an object to be updated without knowing the type and resource ID in advance.
> 
> We solved your particular use case by using the /user_info endpoint from OpenID Connect, and since I see you are using bearer tokens, you might look at that as well.
> 
> --Dale
> 
>> With the current spec - to get the details of a specific user we use the following...
>> 
>> How about having a pre-defined userid - which will provide back the logged in users info.
>> 
>> GET /Users/me
>> In the above case - the information about the user corresponding to the provided Bearer token will be returned back. This would be similar to Facebook's Graph API.
>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 03:04:50 +0530

I guess we need not to worry about the grant types.. me or self would mean
the user corresponding to the access_token..

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 3:02 AM, Phil Hunt <[email-masked]> wrote:

> There is also the issue of what me or "self" points to given all of the
> OAuth scenarios.  Is it the resource owner, the client_id, what is meant?
> What happens with a client acting on its own authority -- self means the
> client?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Phil Hunt <[email-masked]>
Date: Tue, 5 Feb 2013 13:42:24 -0800

That's my point. Depending on the grant type, there may or may not be a corresponding 'user'.  Sometimes, the client is just acting on its own credential.

Phil

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

On 2013-02-05, at 1:34 PM, Prabath Siriwardena wrote:

> I guess we need not to worry about the grant types.. me or self would mean the user corresponding to the access_token..
> 
> Thanks & regards,
> -Prabath
>