Hi Brian
Thanks for this - it will be very useful for open banking in Europe where
cert based auth is required by law.
I have a few suggestions around wording.
Happy to submit these via pull request if it's helpful.
1. Typo - remove can from 1:
Mutual TLS sender constrained access tokens and m
Mike, Yaron Cheffer and myself have volunteered to write a JWT BCP. It is a
topic on the agenda in the OAuth meeting currently underway.
On Fri, Mar 31, 2017 at 9:58 AM, Dave Tonge
wrote:
> Thanks Mike
>
> I agree with all the next steps, we need some articles to help combat the
> FUD that is be
As mentioned during the Chicago meeting the "invalid_target" error code
that was added in -07 was intended to give the AS a standard way to reject
request with multiple audiences/resources that it doesn't understand or is
unwilling or unable to process based on policy or whatever criteria . It
was
Thanks Mike
I agree with all the next steps, we need some articles to help combat the
FUD that is being spread.
Is there any action on who will write those articles?
Dave
On 29 March 2017 at 21:08, Mike Jones wrote:
> Yaron Sheffer had asked me to give an update on JOSE/JWT security to the
> S
and a typo - "If thie location is" should say "If this location is"
On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell
wrote:
> BTW, the intro still has text about 'dynamic parameters such as "state"'
> that need to be cleaned up. https://tools.ietf.org/html/
> draft-ietf-oauth-jwsreq-13#section-1
BTW, the intro still has text about 'dynamic parameters such as "state"'
that need to be cleaned up.
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13#section-1
On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell
wrote:
> "The current text causes the AS to ignore them and not return a error. "
"The current text causes the AS to ignore them and not return a error. " -
except that I don't believe the current text actually specifies that
anywhere. And I think that the intent of Mike's original comment was that
-13 doesn't specify the behavior but that it needs to be revised to do so.
I'd s
Hi John
I see a line in our implementation checking that if a response_type is
also available as a query parameter then it must match the request claim
value.
Would it make sense to require checking all the well-known query
parameters and if they exist - enforcing they must also be available i
