Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

[William Denniss]

I support the adoption of this draft by the working group.

On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> +1 for adoption
>
> Am 21.04.2017 um 21:43 schrieb Nat Sakimura :
>
> +1 for adoption
>
> On Apr 21, 2017 9:32 PM, "Dave Tonge"  wrote:
>
>> I support adoption of draft-campbell-oauth-mtls
>>
>> As previously mentioned this spec will be very useful for Europe where
>> there is legislation requiring the use of certificate-based authentication
>> and many financial groups and institutions are considering OAuth2.
>>
>> The UK Open Banking Implementation Entity has a strong interest in using
>> this spec.
>>
>> Dave
>>
>> On 20 April 2017 at 17:32, Hannes Tschofenig 
>> wrote:
>>
>>> Hi all,
>>>
>>> based on the strong support for this document at the Chicago IETF
>>> meeting we are issuing a call for adoption of the "Mutual TLS Profiles
>>> for OAuth Clients" document, see
>>> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
>>>
>>> Please let us know by May 4th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Ciao
>>> Hannes & Rifaat
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>> --
>> Dave Tonge
>> CTO
>> [image: Moneyhub Enterprise]
>> 
>> 10 Temple Back, Bristol, BS1 6FL
>> t: +44 (0)117 280 5120 <+44%20117%20280%205120>
>>
>> Moneyhub Enterprise is a trading style of Momentum Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Momentum Financial Technology is entered on the
>> Financial Services Register (FRN 561538) at fca.org.uk/register.
>> Momentum Financial Technology is registered in England & Wales, company
>> registration number 06909772 © . Momentum Financial Technology Limited
>> 2016. DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this company may
>> be monitored and recorded for legitimate purposes relating to this
>> company's business. Any opinions expressed in this email (or in any
>> attachments) are those of the author and do not necessarily represent the
>> opinions of Momentum Financial Technology Limited or of any other group
>> company.
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-13: (with DISCUSS)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwsreq-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
DISCUSS:
--

Thank you for addressing my DISCUSS about use of RFC 6125.

I have one  new small issue from your recent change in In 5.2.3 (that was
addressing my comment to include a response example): the example doesn't
include Content-Type and (possibly) Transfer-Encoding header fields.
Without these it doesn't look syntactically correct.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-13: (with DISCUSS)

[John Bradley]

Thanks.  We will try to address that today.

John B.

On Apr 24, 2017 7:16 AM, "Alexey Melnikov"  wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-jwsreq-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for addressing my DISCUSS about use of RFC 6125.
>
> I have one  new small issue from your recent change in In 5.2.3 (that was
> addressing my comment to include a response example): the example doesn't
> include Content-Type and (possibly) Transfer-Encoding header fields.
> Without these it doesn't look syntactically correct.
>
>
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

[Brian Campbell]

One more thing, this document really should register "iss", "aud", and
"exp" (and maybe other common JWT claims that are about the token itself
like "jti", "iat", etc) as authorization request parameters in
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
because the parameter names and claim names collide when using a JWT
Secured Authorization Request.

On Tue, Apr 4, 2017 at 9:41 AM, Nat Sakimura  wrote:

> Thanks Brian for spotting these. I will make the corrections in -14.
>
> Best,
>
> Nat
>
> On Fri, Mar 31, 2017 at 10:40 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
> and a typo - "If thie location is" should say "If this location is"
>
> On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <
> bcampb...@pingidentity.com> 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
>
> On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
> "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 suggest that the doc say that the client must include in the request
> object (request or request_uri) all the oauth parameters that it sends. And
> when request or request_uri is sent, that the AS must/should only rely on
> parameter values from the request object.
>
> I think being semi or somewhat compatible or tolerant of the Connect
> variation or request/request_uri is good because it uses the same parameter
> names, the same endpoint, and the same metadata names.
>
>
>
>
>
>
> On Thu, Mar 30, 2017 at 11:14 PM, John Bradley  wrote:
>
> They are mutually exclusive.
>
>
>
> However there are two options as to how the authorization endpoint would
> treat extra query parameters like state if they are sent.
>
>
>
> The current text causes the AS to ignore them and not return a error.
> This would be more backwards compatible with the request object in OpenID
> Connect, however in reality it may cause connect clients to send parameters
> as query parameters  that would be processed by a connect server that would
> be ignored by a OAuth server without any obvious error.  There may however
> be subtle errors downstream from missing parameters.
>
>
>
> The other option is to have a cleaner breaking change from Connect and
> have the Authorization endpoint return a error if anything other than the
> two new parameters are sent to the authorization endpoint.
>
>
>
> I am leaning towards the latter as it is easier to debug,  and wont allow
> incompatible Connect requests to be accepted without a error.   We would
> have done this in Connect but couldn’t drop required parameters from OAuth
> in a Connect spec.
>
>
>
> The downside for the latter is that the client would need to know if the
> AS is supporting The Connect version or the OAuth version.
>
>
>
> One of the typical conundrums around how to deal with doing the best going
> forward thing vs not blowing up older implementations.
>
>
>
> In the current proposal a client could put the required parameters both
> places and the same request would work on servers supporting both the
> Connect and OAuth versions.
>
>
>
> John B.
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Torsten Lodderstedt 
> *Sent: *March 30, 2017 11:01 PM
> *To: *John Bradley 
> *Cc: *Nat Sakimura ; Nat Sakimura ; 
> IETF
> oauth WG 
> *Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
> I had assumed using the request object is mutual exclusive to use of URI
> query parameters. Did I misinterpret the draft?
>
>
>
> Am 30.03.2017 um 22:40 schrieb John Bradley :
>
>
>
> It is a trade off between compatibility with Connect and possible
> configuration errors.
>
>
>
> In reality it may not be compatible with Connect if the client is sending
> some parameters outside the object without including them in the object as
> a Connect client might.You would potentially wind up dropping state or
> nonce without an error.
>
>
>
> I asked Mike and he was leaning to making it a error to send them as query
> parameters as that would be a clean change.
>
>
>
> I think the choice is a bit of a grey area.
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *sakim...@gmail.com
> *Sent: *March 30, 2017 9:57 PM
> *To: *John Bradley ; Nat Sakimura 
> *Cc: *IETF oauth WG 
> *Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
> +1
>
> Sent from my Huawei Mobile
>
>
>
>  Original Message 
> Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
> From: John Bradley
> To: Nat Sakimur

[OAUTH-WG] AD review of draft-ietf-oauth-native-apps

[Kathleen Moriarty]

Hello,

Thanks for taking the time to document this best practice and the
implementations in the appendix. I have one comment and a few nits.

Security Considerations:
I think it would go a long way to organize these as ones that apply to
this best practice and ones (8.1 and the example in 8.2) about
alternate solutions.  This could also be done through some added text,
but making this clear would be helpful.  Maybe moving 8.1 and 8.2
until after the rest of the sections would be enough and then clearly
state the intent of this text.

IANA Section:
Just a note - you might get some questions about this, but i do think
it's fine to leave that text, although unnecessary.

Nits:
Section 5, punctuation
OLD:
   By applying the same principles from the web to native apps, we gain
   benefits seen on the web like the usability of a single sign-on
   session, and the security of a separate authentication context.
NEW:
   By applying the same principles from the web to native apps, we gain
   benefits seen on the web, like the usability of a single sign-on
   session and the security of a separate authentication context.

The document has text that says 'native app' in some places and 'app'
in others, I assume these are used interchangeably?  It seems that
they are used interchangeably.


Really nitty:
Section 7.2,
Since you are still in the example, did you mean URL in the following:

Such claimed HTTPS URIs can be used as OAuth redirect URIs.
Such claimed HTTPS URLs can be used as OAuth redirect URIs.

And again in the last paragraph of this section.

I'm only asking since you specify URL earlier in this section, so you
were more specific for the example and then drop back to URI (which is
correct, but wondering if you wanted to continue at the same level of
specificity or if there was a reason to just say URI here.

Section 8.11
s/uri/URI/


-- 

Best regards,
Kathleen

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth