<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">If you want to get and edit per-user
information and specify who you're talking about explicitly, don't
use the userinfo endpoint. <br>
<br>
Instead, use SCIM, or something like it. It already has mechanisms
to do different kinds of queries and filters for users, as part of
the request parameter set, and is a much better fit for this type
of situation.<br>
<br>
So long as you back the user information by the same data
repositories, clients should be able to make use of both endpoints
with no problems.<br>
<br>
-- Justin<br>
<br>
On 09/17/2012 01:27 PM, Dale Olds wrote:<br>
</div>
<blockquote cite="mid:50575D70.50508@vmware.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
If I understand the original use case, a client wants to get
claims about a specific subject, but does not have the subject's
access token with scope openid, etc. Therefore, it is natural to
use a client credentials grant, but the client just needs a way to
specify the subject to the /userinfo endpoint. <br>
<br>
We see this pattern quite frequently, but we did not extend the
/userinfo for per-subject client use. It would be hard to predict
all the ways in which a client application may want to get
information about users and potentially modify the user info.
Some applications need a small bit of info about the user, some
start off that way and then turn into are rather substantial user
account management apps. So the usual pattern for our system is to
use client credentials grant and the scim protocol for info
regarding other subjects (uses), and Connect for
authentication/userinfo stuff. <br>
<br>
I'd like to support Connect as much possible, but I guess the
question is purpose of the protocol. If a client wants to get
information about a user for which it does not have a token (i.e.
it is not operating on behalf of that user), then I would think
it's making a directory service request.<br>
<br>
--Dale<br>
<br>
<div class="moz-cite-prefix">On 09/17/2012 06:49 AM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:4D7F8861-B36C-4440-97AF-F7071F59E5B7@ve7jtb.com"
type="cite"> In some ways it is standard OAuth , but standard
OAuth doesn't specify how identify the subject , request claims
or retrieve the result.
<div><br>
</div>
<div>You could do all of that from scratch, but it may be useful
to use what already exists in Connect. That could be done as
part of Connect or a separate spec that profiles Connect.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On 2012-09-17, at 2:30 AM, Torsten Lodderstedt <<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Hi John,<br>
<br>
ressource owner password credential grant makes definitely
sense in my opinion. I'm not sure for client credentials,
esp. w/o id_token, as this boils down to standard OAuth to
get access to the user info endpoint.<br>
<br>
Regards,<br>
Torsten.<br>
<br>
<div class="gmail_quote"><br>
<br>
John Bradley <<a moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>
schrieb:
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Last week I had several conversations with FICAM people around OAuth and Connect.
One thing that they do and is also not uncommon in enterprises is permission access based on client credentials.
Think SAML Attribute query.
We do have that in OAuth 2.0.
One thing we don't say in Connect is how to support that grant_type.
It seems fairly strait forward that you would have a scope of openid and any other user_info related scopes, that nonce and state are not required.
Returning a id_token probably doesn't make sense.
To specify the user who is the subject we already have a way of passing the required user_id in the request object.
I can see this being useful to compliment or replace a SAML/SOAP flow.
We don't specifically talk about this or the Resource owner Password credentials Grant.
As
long as we don't do something in the core specs to preclude them we could put them in a separate profile as they are sort of special case.
John B.
</pre>
<div style="margin-top: 2.5em; margin-bottom: 1em;
border-bottom-width: 1px; border-bottom-style:
solid; border-bottom-color: rgb(0, 0, 0); "><br
class="webkit-block-placeholder">
</div>
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px"><hr>
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>