>From an OAuth point of view, the UserInfo endpoint is just another protected resource. From an OpenID Connect point of view the ability to deliver claims is critical functionality and inseparable from the goals of OpenID Connect.<div>
<br></div><div>=nat<br><br><div class="gmail_quote">On Wed, Apr 4, 2012 at 4:50 AM, Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tend to view things conceptually in much the same way that Justin does. And I think the distinction is an important one.<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Tue, Apr 3, 2012 at 8:43 AM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    This feels like it is moving back to the original OpenID fallacy --
    have only the basic authentication at the middle and all profile and
    other useful information tacked on later. I think that the
    UserInfoEndpoint is a key capability to the Connect protocol.
    Otherwise, it's just OAuth2 with a fancypants token that dumb
    clients can't read.<br>
    <br>
    Here's how I've been splitting it up, conceptually:<br>
    <br>
    - The ID token is for session-bound claims. These include the
    unique ID of "current user" as per the issuer, and we are planning
    to extend the claims here with things like the authentication mode
    that the user used on the way in.<br>
    - The UserInfo Endpoint is for longer-term claims like profile
    information. These include things like the user's name, photo URL,
    email address, and all that. <br>
    <br>
    Is this off the mark? If not, it seems to me that both pieces are
    essential to the structure of the protocol.<span><font color="#888888"><br>
    <br>
    -- Justin</font></span><div><div><br>
    <br>
    On 04/02/2012 06:40 PM, John Bradley wrote:
    <blockquote type="cite">
      <pre>So we would still define the scopes and claims without defining the endpoint?

I am guessing that would move requesting signed/signed+encrypted responses from registration to the new spec as well?

John
On 2012-04-02, at 7:30 PM, Anthony Nadalin wrote:

</pre>
      <blockquote type="cite">
        <pre>I would think that the basic profile could mandate the required claims and not the UIEP specification

-----Original Message-----
From: John Bradley [<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">mailto:ve7jtb@ve7jtb.com</a>] 
Sent: Monday, April 02, 2012 1:59 PM
To: Nat Sakimura
Cc: Anthony Nadalin; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
Subject: Re: [Openid-specs-ab] Feedback to implementators draft

The question is what effect making the user_info endpoint optional would have on interoperability.

Or is the intention to make attributes optional?

The only required claim being the user_id in the id_token.

That pushes back against the original design of providing a standard set of common registration information.

John B.
On 2012-04-02, at 5:55 PM, Nat Sakimura wrote:

</pre>
        <blockquote type="cite">
          <pre>UserInfo endpoint IS just a regular OAuth 2.0 protected resource. +1
for factoring out and others.

=nat via iPhone

On 2012/04/03, at 5:35, Anthony Nadalin <a href="mailto:tonynad@microsoft.com" target="_blank"><tonynad@microsoft.com></a> wrote:

</pre>
          <blockquote type="cite">
            <pre>+1 to all items on the list here as it will make for a easier to implement specification

I would also like to see the information endpoint factored out of the messages specification into its own. This could also be pointed to by the basic client profile if desired but the information endpoint should just be an example of a OAUTH 2.0 endpoint.

-----Original Message-----
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Torsten Lodderstedt
Sent: Saturday, March 31, 2012 1:43 PM
To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
Subject: [Openid-specs-ab] Feedback to implementators draft

Hi all,

I want to give you some feedback regarding the implementators draft based on ongoing discussions at Deutsche Telekom and other operators. We are currently considering to use OpenID Connect for two purposes:

1) There is an initiative to expose our login capabilities (e.g. based on SIM cards) to application developers via an standardized interface.
For the first phase, we decided to go with OpenID 2.0. For the next phase, we are considering to migrate to OpenID connect because of its superiour capabilities regarding mobile apps and its alignment with OAuth 2.0 (which already is the authorization protocol of choice for other Telco APIs).

2) We use OpenID 2.0 with some extensions for session management and token handling internally at Deutsche Telekom for our consumer products.
Clearly, OpenID connect would be the next logical step in order to get rid of the propietary stuff and come up with a better OAuth integration.

For both use cases, we think simplicity is, beside security, a critical success factor. There are a couple of aspects that currently prevent us from adopting OpenID connect and I want to share those with you along with some suggestions how to cope with them.

1) Client Basic Profile
In my opinion, the basic client profile should support the straight-forward implementation of any kind of application. I currently see issues regarding web and mobile apps and would therefore propose the following changes:

1.1) Use grant type code instead of implicit grant
I would suggest to change the Basic Client Profile to use authorization codes instead of the implicit grant. In my opinion, code has the following advantages:
- It is simpler to implement for web applications.
- It is better suited for mobile apps because of the support for refresh tokens.
- The ability to transmit large user data chunks over a back channel instead  of the front channel is beneficially for mobile web applications, which most likely run on high latency, low bandwitdh network connections.
- It is more secure due to the transmission of longer-lasting secrets via back channels only.

1.2) Drop the need for signature validation in basic profile
Because of the direct TLS-protected connection between RP and AS on the tokens endpoint, the RP no longer needs to validate the digital signature of an id token. This is because the authenticity of the issuer is already ensured by TLS server authentication. This would further simplify RP implementations and follow the OAuth 2.0 spirit to avoid signatures if possible. Clearly, signature validation is still needed for all indirect tranmissions of id tokens.

1.3) Drop nonce from basic profile
I would suggest to remove nonces from the basic profile and instead use TLS and a single-use restriction on authorization codes to prevent token replay. This is inline with the defintions given in the security consideration section of the OAuth core spec and further simplifies implementations.

In 10.12, it is stated that any client must prevent XSRF:

"The client MUST implement CSRF protection for its redirection URI."
"The client SHOULD utilize the "state" request parameter ..."

10.5 requires:
"Authorization codes MUST be short lived and single use."

and also states TLS MUST be used to protect the redirect endpoints of clients, which use OAuth for login functions, which clearly holds for OpenId Connect RPs.

"Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require TLS."

2) General proposals
Regarding the overall specification, I would like to suggest the following changes:

2.1) removal of checkid endpoint
As stated above, Id tokens don't need to be verified for direct connections. Even if the RP (or any other party) needs to validate it, the verification of id tokens is simple given the adoption and simplicity of JWT. So I don't see a need for this function.

2.2) removal of symmetric signatures for id tokens
I think the spec could benefit from removing support for symmetric signatures and support asymmetric signatures, only. RPs (even public
clients) could validate signatures based on the AS's public key. Interop would benefit because of the reduced numbers of algorithms, security would benefit because of the limited applicability of symmetric signatures (two parties only!). Moreover, dual use of client secrets for authentication on the AS (original use case) and creation/validation of digital signatures would put to an end.

What do you think?

best regards,
Torsten.
_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>





_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
          </blockquote>
          <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
        </blockquote>
        <pre></pre>
      </blockquote>
      <pre></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>

</div>