I was considering preparing an "extended scopes" concept draft to define both a
target parameter (what we're using "aud" for) as well as a temporal parameter,
to sit beside scope which is more naturally an "extent of permission".
We need the audience bit for HEART, and I know others that do as well.
I propose we define an extended scopes document like this to capture a couple
categories like that. Good news is that we do have some implementation
experience from both ping and Microsoft on this.
-- Justin
/ Sent from my phone /
-------- Original message --------
From: Brian Campbell <bcampb...@pingidentity.com>
Date: 11/7/2015 7:56 AM (GMT+09:00)
To: Hannes Tschofenig <hannes.tschofe...@gmx.net>
Cc: oauth@ietf.org
Subject: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG
Meeting Minutes)
That's right, sorry, there's not actually a conflict now as the PoP key
distribution draft currently only uses the 'aud' parameter at the token
endpoint.
I just assume it will end up being used at the authorization endpoint
eventually because the need to disambiguate where the token will be used isn't
limited to the token endpoint (we do have this implicit thing). As John
mentioned, we have used an 'aud' parameter (interpreted as a resource location)
in our AS on both endpoints to allow the client to indicate where it intends to
use the token it's asking for, which enables the AS to apply unique policy to
that token for the given resource (it's not the exact same thing as PoP key
distribution but conceptually similar). So I was confusing implementation
experience with what was actually in the PoP key distribution draft.
That said, I do think that JAR should register JWT claims that it's likely to
use in the Request Object as authorization endpoint parameters to avoid this
kind of conflict.
And I something like the 'aud' parameter is needed at both the token and
authorization endpoints so PoP key distribution should use a different name.
Or this potential independent draft, which I do think has value. I was planning
on proposing something that's based on similar parameters being worked on in
token exchange - we're just not there quite yet.
On Fri, Nov 6, 2015 at 6:03 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net>
wrote:
Brian also pointed out that there is a conflict with the PoP key
distribution draft that uses the 'aud' parameter. John noted that
currently the 'aud' parameter is used towards a different endpoint, used
as a query parameter, but it would probably be good to take this into
account now.
Justin noted that there is general utility to indicate the audience.
Today people are forced to use the scope for WHAT, HOW and HOW LONG the
client wants to access a protected resource. The 'aud' describes the
WHAT aspect. He suggested to take it a general utility extension that
is indepdent of the PoP document.
Hannes added a remark that the 'aud' parameter / claim was a separate
document and then we added it to the PoP document.
John said that we didn't had the wide-enough picture and we now
understand things better.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
