So, Mike,
Authorized Presenter is a defined term in Sender Constrained JWT for OAuth
2.0
( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 ). It is
used in the context of OAuth 2.0 Access Token, not a claim in ID Token of
OpenID Connect.
Nat
2015-08-19 11:44 GMT+09:00 Mike Jones :
Sorry OAuth folks: I have mistakingly Cc: all'ed. This is OpenID Connect ID
Token stuff and not pertinent to OAuth WG per se nor this discussion which
was about the access token. I should have removed the list from Cc:.
I will respond more stuff directly related to the original thread
subsequently
The “azp” description was changed after the in-person OpenID Connect working
group meeting at Google on 6-May-13, in which we agreed that “azp” would be
used to represent the issued-to information, and that the claim would be named
“Authorized Party”. See the meeting notes at
http://lists.open
I have dug into it why it ended up like that. The approved text per the
ticket #712 and #830 was:
azp
OPTIONAL. Authorized Presenters.
This member identifies OAuth 2.0 Client(s) and potentially
other parties authorized to use this ID Token as an assertion
of the identity of the ID Toke
Inline:
2015-08-11 14:12 GMT+09:00 Mike Jones :
> Replies inline…
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura
> *Sent:* Wednesday, March 25, 2015 6:38 AM
> *To:* oauth
> *Subject:* [OAUTH-WG] Review Comments for
> draft-ietf-oauth-proof-of-possession-02
>
>
>
Thanks. I am working on your response now.
2015-08-11 14:24 GMT+09:00 Mike Jones :
> I believe that I’ve now responded line-by-line to all the WGLC comments
> received. If I missed any from any of you, please let me know.
>
>
>
> After discussion of my responses this week, unless disagreements a
Just as a point of clarification, the definition of the “azp” claim is not
“authorised presenter”. At least as defined by OpenID Connect, its definition
is:
azp
OPTIONAL. Authorized party - the party to which the ID Token was issued. If
present, it MUST contain the OAuth 2.0 Client ID of this
It is not directly, but Sender Constrained JWT for OAuth 2.0
( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 )
talks about a model that allows it.
In essence, it uses a structured access token that is sender constrained.
It as a claim "azp" which stands for authorised presenter.
To
+1
2015-08-15 4:20 GMT+09:00 Phil Hunt :
> +1
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> On Aug 14, 2015, at 12:08 PM, John Bradley wrote:
>
> +1
>
> On Aug 14, 2015, at 3:03 PM, Brian Campbell
> wrote:
>
> +1 for "rba"
>
> On Fri, Aug 14, 2015 at 11:52 AM, W
Sorry for a tardy reply.
You are right. My +1 was for flattening.
Also, my comment around 3.4 was not an implicit endorsement for having
structured cnf claim. I was merely pointing out that it is a bad practice
to use a defined term before it being defined.
Nat
2015-08-12 1:41 GMT+09:00 Brian Ca
Seems the consensus here is clearly in favor of keeping the "cnf" claim as
it is. I'll let the flattening suggestion go gentle into that good night.
On Tue, Aug 18, 2015 at 1:33 PM, Anthony Nadalin
wrote:
> I would rather just keep the "cnf" claim rather than flatten the structure
> since we are
I would rather just keep the "cnf" claim rather than flatten the structure
since we are already using the "cnf" in production with the XBOX One. We are
also using multiple conformation keys and using the "cnf" claim makes it
easier to have multiple confirmation keys (by just defining a new clai
12 matches
Mail list logo
