Hi Phil,
thanks for your response. A few remarks below.
>> I am particularly interested to learn who issues the initial
>> access token and the software statement? What is the purpose? What
>> does it authorize?
>
> These tokens have very different characteristics. The Software
> Statement is no
One other small remark: I assume that a single software statement is
distributed to many OAuth clients whereas the initial access token is
only distributed to a single OAuth client. Is that correct? Is that the
envisioned relationship?
On 06/12/2014 09:50 AM, Hannes Tschofenig wrote:
> Hi Phil,
>
Hi Mike,
thanks for your quick response.
On 06/05/2014 07:46 PM, Mike Jones wrote:
> Hannes, the Access Token and ID Token do quite different things and
> have different structures and properties. The Access Token is an
> opaque value that grants access to resources. An ID Token is a
> non-opaq
Hi Mike,
thanks for responding also to the question about dynamic client
registration.
I also believe it would be useful to add information in the draft about
the opaqueness nature of the different tokens, i.e., who is supposed to
read them.
From the current wording of the document my understand
On 06/05/2014 09:20 PM, Bill Mills wrote:
> Can't agree more with the peril of overloading auth information into an
> access token.
Explain that a bit more, Bill.
I think we should to provide a design rational so that a reader who has
not participated in the standardization process understands t
Torsten,
nobody suggested that the access token would suddenly not be opaque to
the client.
The question therefore is whether the id token is not opaque to the
client. Is that the assumption?
On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
>
> the access token is opaque to the client. That's
The token introspection is useful when you use an access token that is
just a reference (instead of passing the values around using a JWT).
Using token introspection on the access token to get the content of the
access token in addition to the ID token will still get you the same
data twice (at le
Only a short note: We haven't standardized a delegation mechanism yet
and the proposals we had discussed in the past did not require the
client to understand the content of the access token even for delegation.
Having said that I would like to note that it still required the AS to
send additional
The argument about confusing draft-hunt-oauth-v2-user-a4c-03 with the
OpenID Connect work is indeed something to be careful about. Maybe this
could be addressed by more precisely capturing the differences in a
section of the document.
Ciao
Hannes
On 06/05/2014 10:11 PM, John Bradley wrote:
> Loo
Hi Kathleen,
on the first item I have a few minor remarks: You wrote:
"
As I read through the Algorithms (JWA) draft there are some changes that
will need to be made to avoid problems during the IESG review. This is
a pretty big change for the draft, but will help make the review and
approval fa
The Id_token is audienced to the client. It is not sent to a resource server.
In a4c there may be no access token or resource server.
The id_token is not opaque to the client.
John B.
Sent from my iPhone
> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig
> wrote:
>
> Torsten,
>
> nobody
Right, and the original question in this part of the thread was "why
bother with an ID token, why not just re-use the access token for both
purposes?"
Torsten's response below was in answer to that -- merging these two
would make the access token non-opaque to the client. This is
undesirable
The response from the token endpoint has multiple parameters.
There is no reason to put information the client needs in the access token.
That creates more problems than it solves.
John B.
Sent from my iPhone
> On Jun 12, 2014, at 4:14 AM, Hannes Tschofenig
> wrote:
>
> Only a short no
+1 to Hannes comments.
Hi Mike,
thanks for your quick response.
On 06/05/2014 07:46 PM, Mike Jones wrote:
Hannes, the Access Token and ID Token do quite different things and
have different structures and properties. The Access Token is an
opaque value that grants access to resources. An ID
Hannes,
What I was attempting to describe regarding OpenID is an independent
organization that controls an API. I think the problem with “publisher” may be
that there is confusion between publishing the software vs. publishing the API
specification. Either is appropriate.
OpenID seemed like a
The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen engineers within the OpenID community.
The a4c draft proposal is 15 pages and will receive review from 100s of
engineers within the world's most advanced standards body the IETF.
It's a no b
I don’t think so. All copies of a client may carry the same statement.
Special distributions of a client intended for use in a specific domain may be
packaged with an initial access token. So a subset of every client may have
the token.
All clients registering within a secure domain would have
Hannes,
I should also add one security consideration.
If a server believes it is receiving a registration request from a client
sharing the same software_id and software_version as another client that uses
an assertion, the server should find the registration suspect. It is likely the
client i
One of the use cases is to return only a token that is NOT an access token and
is only an authentication assertion that is not opaque to the client.
A key concern is clients do not always want to ask users for consent to access
their profiles or any other resource. They just want authentication
On 6/12/2014 12:49 PM, Prateek Mishra wrote:
The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen engineers within the OpenID community.
The OpenID Connect spec is 86 pages because it pretty much rehashes the
OAuth2 spec walking through each
Phil
> On Jun 12, 2014, at 12:50, Bill Burke wrote:
>
>
>
>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>> received review from maybe a dozen engineers within the OpenID community.
>
> The OpenID Connect spec is 86 pag
+1, after implementing OIDC I will support the claim that any SSO
protocol with a minimal set of required features smaller than OIDC is
insecure and any protocol with similar features but with different
parameter names is just creating confusion and will increase chances of
non-interoperable an
One problem we've discovered when returning the client_id value as "sub"
is client impersonation. That is, in a system where a user can
self-register, it's possible that the user could register an id/sub value
that is the same as the client_id value, and thus be granted the same
privileges as
All but a handful of OAuth WG participants participated in developing OpenID
Connect.
Yes some companies chose not to participate for whatever reasons and have not
committed to the mutual non assert IPR agreement, and that is unfortunate, but
not a reason to start again from scratch.
Changin
I haven’t touched the draft for a while because the basics have fit most of our
use cases and there hasn’t been a clamor from the working group to standardize
it. I’d be happy to pick it back up if the working group wanted to make it an
official document.
Having run this in production for a lit
> I’d be happy to pick it back up if the working group wanted to make it
an official document.
+1
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com
From: Justin Richer
To: Todd W Lainhart/L
26 matches
Mail list logo
