___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
IMHO the sub claim should always refer to the user - and nothing else.
OIDC says:
"Subject - Identifier for the End-User at the Issuer."
client_id should be used to identify clients.
cheers
Dominick
On 25. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote:
Hi Vittorio,
Thanks for t
Without agreeing or disagreeing: OIDC does not apply here since it is not
OAuth and an access token is not an id_token.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
"The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a JW
Nice work Vittorio.
I think the "sub" claim can also be used to reference the client (depending
on the implementation may not necessarily map to the client_id). It might
eventually reference the same entity as the client_id.
In addition to the "sub" claim, does it make sense to explicitly have
th
JWT
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Yes I know - and I think in hindsight it was a mistake to use the same
claim type for multiple semantics.
All the “this is OIDC not OAuth” arguments are making things more
complicated than they need to be - in my experience almost no-one (that I
know) does OIDC only - nor OAuth only. They always c
Hi Vittorio,
Very nice work !
Here are a few ideas:
- In addition to the "sub" claim (I agree it should only relate to the end
user, not the client_id), I think the scope claim should be mentioned as
OPTIONAL in §2.2 (it's already mentioned in other parts of the draft)
- Should we mention secur
I believe there are plenty of OAuth 2.0 only use cases out there... but
nevertheless I agree with the potential confusion and thus security
problems arising from that (though one may argue the semantics are the
same).
Hans.
On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier
wrote:
> Yes I know - an
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JSON Web Token Best Current
Practices'
as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please sen
e.g., bad password
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
All rights reserved.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Dominick,
While you assumption of how OIDC and OAuth are used may apply to Federated
solutions, the North American Energy Standards Board (NAESB) Energy Service
Provider Interface (ESPI) REQ.21, which defines the data transmission standard
for Energy utilities (electricity, gas, and water) t
I am re-sending the conclusion summary email following the discussion about the
implicit grant, as discussed in the OAuth WG meeting in Prague today.
https://mailarchive.ietf.org/arch/msg/oauth/mLWi6wji31qOkciSgPjXPK98ydc
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachmen
Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID
Connect core, hence Dominick observation is on point. However
Thank you Bertrand for your comments and kind words!
Inline
> In addition to the "sub" claim (I agree it should only relate to the end
> user, not the client_id),
See the reply to Dominick & Hans on this. Do you have specific case/attack
in mind?
I think the scope claim should be mentioned as O
Thanks Don for your perspective on this!
On Mon, Mar 25, 2019 at 10:13 AM wrote:
> Dominick,
>
>
>
> While you assumption of how OIDC and OAuth are used may apply to Federated
> solutions, the North American Energy Standards Board (NAESB) Energy Service
> Provider Interface (ESPI) REQ.21, which
Hi Vittorio,
Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or
incremental integer as sub & client_id will be easily collide.
If you can enforce collision resistant IDs between user & client instances,
it’ll works fine. I
>From an access token consumer (aka API) developer point of view, I prefer
this logic
"If sub is present - client acts on behalf of a user, if not - not."
Anything more complicated has a potential of going wrong.
On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote:
Hi Vittorio,
18 matches
Mail list logo
