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

[Samuel Erdtman]

+1 for adoption

On Mon, Apr 24, 2017 at 9:02 AM, William Denniss 
wrote:

> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

Hi,

On Tue, Apr 25, 2017 at 9:09 AM, John Bradley  wrote:
> Thanks Kathleen,
>
> William and I will address these shortly.
>
> We can take out the IANA section completely if you think it is better.

No, I think it's fine.  Let's see what happens.  It could be helpful
text for some readers, I was just pointing out that some questions may
arise.

>
> In the current implementations on Android and iOS Universal Links/App Links 
> and  are only http or HTTPS schema URI making them URL.
>
> So while all URL are URI, we could be more specific if that is OK with the 
> style police.  I thought the URL term was currently discouraged..

You have it in a couple of places already, so consistency would be
easier to argue if you felt it was needed in the places where it is
already, hence my comment.  I can't be sure what the URI style police
will say, but consistency helps in most situations.  If this is
specific to an example, that's fine.  If the general pattern could be
a URI (not a URL), then just be sure that is clear in the text.

Please let me know when it is ready and I'll start the IETF last call.

Thanks,
Kathleen


>
> John B.
>
>
>> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty 
>>  wrote:
>>
>> 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
>



-- 

Best regards,
Kathleen

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

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

[John Bradley]

Thanks Kathleen,

William and I will address these shortly.

We can take out the IANA section completely if you think it is better.

In the current implementations on Android and iOS Universal Links/App Links and 
 are only http or HTTPS schema URI making them URL.

So while all URL are URI, we could be more specific if that is OK with the 
style police.  I thought the URL term was currently discouraged..

John B.


> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty 
>  wrote:
> 
> 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



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