Hello,
I have a question regarding "JWT Response for OAuth Token Introspection"
(draft-02).
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/?include_text=1
How to determine the value of "aud" in the response JWT?
The example payload uses "https://protected.example.n
Let me try a different angle. An AS might generate sub claims and client_id
identifiers using a different format/template. That means that there might
be a client with client_id X that gets assigned a sub value Y, despite the
client being the same, hence the check “sub==client_id” would fail.
The l
I'm suggesting that whichever "sub" and "client_id" the RS is receiving and
however it was generated, it must mean something to it in alignment with
the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; moreover,
if the "sub" has the same value as "client_id" it must be a client talking
I am not following. We want this to be adopted, right? :) if we provide
guidance that is sound but hard to implement we are going to fail.
Considerations on whether the guidance requires a big effort to be applied
are very much in scope for me.
On Mon, May 6, 2019 at 14:54 Hans Zandbelt
wrote:
>
the scope and way of generating sub/client_id is orthogonal to the
semantics IMHO but if I'm the only one who thinks so, I'll rest my case
Hans.
On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci
wrote:
> See below, Hans- the sub doesn’t have to be global, it could be something
> generated just
See below, Hans- the sub doesn’t have to be global, it could be something
generated just for this particular RS. Or the AS might have its own recipe
for generating sub values that different from the recipe used to generate
client_ids. It would be much easier for an AS to emit a claim making this
ex
I may be missing something but I'd argue that by requiring and comparing
both "sub" and "client_id" we achieve the same semantics without a
new/additional claim (barring name spacing)
Hans.
On Mon, May 6, 2019 at 8:58 PM Karl McGuinness wrote:
> Makes sense that we don’t want to further couple
In OpenID Connect, aggregated and distributed claims are ways for the
OpenID Provider to reference claims issued by other entities (e.g.
attribute provider or "Issuer" in the SSI sense). There is no
requirement from a spec perspective that the /userinfo endpoint be
co-located with the AS. It se
OAuth 2.0 has its merits and will be around for the next 20 years or so;
yet we're bumping into its limitations every day if not only for its
complexity and the incomprehensibility for regular IT peeps that don't have
the full historical background; support for transactions is obviously
missing tod
On May 6, 2019, at 1:42 PM, Emond Papegaaij wrote:
>
> Hi all,
>
> For a browser-based app, we try to follow the recommendations set in draft-
> ietf-oauth-browser-based-apps-01. This does allow us to create a secure OAuth
> 2.0 browser-based application, but at the moment it comes at a cost wr
Makes sense that we don’t want to further couple AS and RS with grant types.
I’m OK if we want a dedicated claim to establish whether the token is resource
owner delegated vs client acting as itself.
Subject Type is already a concept in RISC. Just making folks are aware of
prior art.
https:
On 06/05/2019 22:26, Vittorio Bertocci wrote:
> I am not following, Vladimir. What do you mean? Can you make some examples
> to clarify?
> The userinfo is always colocated with the AS, hence I would expect most
> vendors not to use JWT for the ATs issued for userinfo access
That's what I was curio
Hi all,
For a browser-based app, we try to follow the recommendations set in draft-
ietf-oauth-browser-based-apps-01. This does allow us to create a secure OAuth
2.0 browser-based application, but at the moment it comes at a cost wrt. user
experience when the access token expires. Our current so
In a vein related to Torsten’s recent thread and blog post, I’ve also been
working on a proposal around Transactional OAuth. As many of you know, I wrote
a blog post about the basic idea last fall, and now I’ve got something a bit
more concrete online that people can poke around with. I’m callin
On zondag 5 mei 2019 15:54:48 CEST you wrote:
> On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij
> > To summarize, I have to following questions:
> > - Is the 'OAuth 2.0 Token Exchange' specification still active?
>
> Yes with the caveats mentioned above. I will say that although there's a
> lot o
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, e.g.
sub_type = [ resource_owner | client ] ?
On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov
wrote:
> Hi Vittorio,
>
> On 06/05/2019 22:22, Vittorio Bertocci wrote:
> > It is true
Hi Vittorio,
On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did think
> about the "client_id==sub" heuristic, but that's not always applicable:
> many systems have their own rules for generating sub, and in case they want
> to preve
It is true that the grant_type is a client side consideration. I did think
about the "client_id==sub" heuristic, but that's not always applicable:
many systems have their own rules for generating sub, and in case they want
to prevent tracking across RSes the sub might be generated ad-hoc for that
p
I am not following, Vladimir. What do you mean? Can you make some examples
to clarify?
The userinfo is always colocated with the AS, hence I would expect most
vendors not to use JWT for the ATs issued for userinfo access
On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov
wrote:
>
> https://tools
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2
In OpenID Connect the access token is consumed by the UserInfo endpoint.
Were there any suggestions to also spec parameter(s) for the claims
names (with optional locales) for release at the UserInfo endpoint?
Vladimir
On 06/05/2019 20:32, Vittorio Bertocci wrote:
> To that end, *Karl MCGuinness suggested that we include
> grant_type as a return claim, which the RS could use to the same effect*. I
> find the proposal very clever, and the people at IIW thought so as well.
> What you think?
The grant type is not s
Hi Rifaat,
On 02/05/2019 23:46, Rifaat Shekh-Yusef wrote:
> All,
>
> As part of the shepherd write-up for the *JWT Response for OAuth Token
> Introspection* draft, we are looking for information about implementations
> for this document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-intr
I don’t know the relative merits of Link headers vs .well-known, but there is
at least one other draft standard I know of that is going down the .well-known
route for this kind of thing (password changes in this case):
https://github.com/WICG/change-password-url/blob/gh-pages/explainer.md
— Nei
Hi Benjamin,
Thanks for the hint. Will give that a shot!
Evert
On 2019-05-06 1:38 p.m., Benjamin Kaduk wrote:
> Hi Evert,
>
> On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote:
>> Hi everyone!
>>
>> I've been running into a number of situations where it would have been
>> beneficial to h
Hi Evert,
On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote:
> Hi everyone!
>
> I've been running into a number of situations where it would have been
> beneficial to have a few protocol/media-type agnositic link relation
> types for user authentication purposes.
>
> https://tools.ietf.o
Hi all,
thanks for your patience during this month long hiatus, and thanks for the
comments.
Last week at IIW I had the opportunity to discuss this with many of the
people on the list. Here's a summary of where the discussion landaed on the
subject of the sub (pun intended).
- It seems that RFC 75
26 matches
Mail list logo
