<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Am 19.05.2010 08:23, schrieb David Recordon:
<blockquote
cite="mid:AANLkTikJjO7whzZv1TL8qPAsUkX3FdHTuIByKEKWRDZq@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
1) In your proposal there are two services providing user data, the
OAuth authorization server and the user data service. Why this
redundancy? Wouldn't the user data service suffice?<br>
</blockquote>
<div><br>
</div>
<div>The model brought forth in WRAP and now preserved in OAuth 2.0
has a separation between the authorization server and one or more
protected resources. I thus view the user info API as one of these
protected resources.</div>
<div><br>
</div>
<div>From conversations at IIW, I'm thinking about removing the
separate user info API endpoint and instead making each user identifier
a protected resource. Thus you fetch <a moz-do-not-send="true"
href="https://server.example.com/wo1k1nklas">https://server.example.com/wo1k1nklas</a>
with no access token and get public data. Fetch it with an access token
from the OpenID response and you get protected information.</div>
<div><br>
</div>
<div>This removes an endpoint and makes the identifier itself quite
useful.</div>
</div>
<br>
</blockquote>
<br>
Sounds good, so you are going to RESTify this part?<br>
<br>
<blockquote
cite="mid:AANLkTikJjO7whzZv1TL8qPAsUkX3FdHTuIByKEKWRDZq@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Why
not split it? What about using another parameter, say "openid_mode", to
activate the extended behavior of the OAuth authorization server? Then,
the scope parameter could exclusively be used to determine the
permissions of the client on the user data service. For example, the
set of attributes accessible to the client could be requested that way.<br>
</blockquote>
<div><br>
</div>
<div>OAuth 2.0 already has a `type` parameter which is used to
differentiate between the different flows. Given that we're
piggybacking on those flows, we don't want to overload that parameter.
Having both `type` and `mode` feels redundant when `scope` is designed
for the client to tell the server it wants more data access.</div>
<div><br>
</div>
<div>Given that the client is asking for user information in addition
to the identifier, it seemed reasonable that would be an additional
scope. Scope is also already the mechanism servers use to determine the
consent UI shown to the user.</div>
</div>
</blockquote>
<br>
I still feel uncomfortable with this "overload" of semantics. So far
the scope determines properties of a token not the behavior of the
authorization server. In my experience, weak semantics causes more
trouble than additional parameters with a clear semantics. I mean, you
propose a significant extension to the services offered by an OAuth
authorization server. It has never before attested identities. So
introducing another flag (choose any name) seems appropriate to me.
Another way would be to introduce a generic name scheme, where every
standard flow may be turned into an OpenId Connect flow just be adding
a suffix, e.g. web_server(_with_id) :-).<br>
<br>
Another question arose:<br>
<br>
"Clients can optionally include a client_id parameter and MUST if they
do not verify the signature within the response. If this parameter is
included and the access token was issued to a different client, the
server MUST return an error."<br>
<br>
Seems you want to prevent token theft? But the proposed design forces a
deployment to share client ids between authorization server and
protected resource - one of patterns of OAuth 1.0a most people wanted
to get rid of with OAuth 2.0. What about using token secrets instead?<br>
<br>
regards,<br>
Torsten.<br>
</body>
</html>