<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi John,<br/><br/>I agree, leveraging existing concepts is better than re-inventing the wheel.<br/><br/>I would propose to specify the UserInfo resource in a separate spec along with the respective scopes.<br/><br/>Regards,<br/>Torsten. <div>Gesendet mit BlackBerry® Webmail von Telekom Deutschland  </div><hr/><div><b>From: </b> John Bradley <ve7jtb@ve7jtb.com>
</div><div><b>Date: </b>Mon, 17 Sep 2012 10:49:34 -0300</div><div><b>To: </b>Torsten Lodderstedt<torsten@lodderstedt.net></div><div><b>Cc: </b>openid-specs-ab@lists.openid.net Group<openid-specs-ab@lists.openid.net></div><div><b>Subject: </b>Re: [Openid-specs-ab] client_credentials grant_type</div><div><br/></div>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 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 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.<br><br>One thing that they do and is also not uncommon in enterprises is permission access based on client credentials.<br>Think SAML Attribute query.<br><br>We do have that in OAuth 2.0.<br><br>One thing we don't say in Connect is how to support that grant_type.<br><br>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.<br>Returning a id_token probably doesn't make sense.<br><br>To specify the user who is the subject we already have a way of passing the required user_id in the request object.<br><br>I can see this being useful to compliment or replace a SAML/SOAP flow.  <br><br>We don't specifically talk about this or the Resource owner Password credentials Grant. <br><br>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.<br><br>John B.<br><br></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><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></pre></blockquote></div></blockquote></div><br></div></body></html>