Re: [OAUTH-WG] OTP-flow use case (sharing energy data)

[Samuel Erdtman]

To me this looks similar to the device flow.

https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13

See figure 1, my interpretation of what you want to do is to split up step
B so that the code goes via another channel and then revers the direction
of C and D.

So maybe you could ride on some of the work done in the device flow draft.





On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler  wrote:

> Howdy,
>
> Rifaat recommended I post to the mailing list. Specifically, I am looking
> for a mentor and feedback on a potential new OAuth flow (currently called
> OTP-flow).
>
> Background:
> I am a participant in the California Public Utility Commission's Customer
> Data Access Committee (CPUC CDAC), and we are working on improving utility
> data access to accelerate deployment of more renewable and energy
> efficiency technologies to fight climate change.
>
> However, we are currently struggling with a use-case for which we can't
> seem to find a good OAuth flow.
>
> Use-case:
> Utility customers want to share their utility data (e.g. historical energy
> usage) with a client (e.g. an energy auditor, to perform some energy
> efficiency analysis).
>
> However, there are two problems that often occur:
>
> 1) Most utility customers do not have online accounts or forgot their
> login information. This makes typical OAuth user interface complex, since
> you have to either create an online account in the flow or do some sort of
> multi-step password-reset/verification process.
>
> 2) Utilities are not strongly incentivized to optimize complex UI/UX for
> the customer in the authorization server interface. In the committee we've
> gotten to the point where we have to specify number of clicks, div height
> requirements, and minimum pageload times for a utility to implement their
> OAuth flows (and then utilities want to charge rate payers for the cost of
> each UI/UX improvement).
>
> So, we have been brainstorming possible ways around these problems, and we
> think it may require a new type of authorization flow using one-time
> passcodes (OTP) instead of redirecting the user to the utility for normal
> OAuth. Luckily, even though utility customers may not have an online
> account at the utility, the utility usually still has (a) a way of uniquely
> identifying them and (b) a way of contacting them (phone, email, etc.).
>
> I'd like to see if the OAuth working group is an appropriate place to help
> develop this flow (or if there has already been work done such a flow). I'm
> happy to write the initial draft, but I would very much appreciate some
> mentorship from someone more experienced in the workgroup.
>
> OTP-flow diagram and example:
> https://pastebin.com/raw/4Gx8LAQ1
>
> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth
> device-flow and authorization code flow. Since we want to avoid asking
> utilities to implement complex authorization interfaces (problem #2 above),
> the client asks the utility to send the user_code directly to the user (via
> text/phone/email), then the client asks the user for the user_code and
> submits it to the utility to get an access token.
>
> Also, there is an initial step of identifying (but not authenticating) the
> user and determining the way in which the OTP code should be sent. If
> utilities are given some sort of non-secret user identification (e.g.
> address, phone number, account number, etc.), they should be able to send a
> user_code to the user that the user can give to the client for
> authorization. Hopefully, this can shift most of the complex UI/UX
> development cost away from the utility and onto the third party clients.
>
> Unfortunately, the energy industry can be quite behind on the latest and
> greatest OAuth developments, but we're trying to get better :)
>
> Thanks very much,
> Daniel Roesler
> dan...@utilityapi.com
>
> ___
> 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] Non-repudiation for API requests and responses

[Samuel Erdtman]

Hi Vladimir

I have published an implementation created by Anders. You can find it here
https://github.com/erdtman/java-json-canonicalization

I have tested to add support for this in a JavaScript JOSE implementation
(node-jose), it was super easy (just hours of work).

Best regards

On Mon, Sep 10, 2018 at 11:11 AM, Vladimir Dzhuvinov <
vladi...@connect2id.com> wrote:

> Hi Samuel,
>
> Thanks for the quick update. Factoring out the c14n to a separate
> independent spec resulted in a much clearer draft. I don't see anything
> missing in terms of spec have it implemented.
>
> Can you suggest a Java library that can handle the c14n 
> (rundgren-json-canonicalization-scheme)?
> We already have the JOSE infrastructure, and I was wondering how we could
> plug in the c14n.
>
> Vladimir
> On 06/09/18 23:20, Samuel Erdtman wrote:
>
> Hi,
>
> A new version has been submitted. It would awesome if we could get some
> comments on the draft and thoughts about a potential future adoption.
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>
> Changes includes the change of canonicalization method and some minor
> clarifications.
>
> Best regards
> //Samuel
>
>
>
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  
>  wrote:
>
>
> Then I’ll post an update within a ~week.
>
> There is one thing that could make implementing even simpler (from my
> experience). That is how to handle multiple signatures. Today the
> specification supports sharing of headers between signatures. If signatures
> instead are completely independent and put in an array at the top level
> cleartext_signature attribute one could just do a minor change to existing
> implementations to support cleartext signatures.
>
> On Wed, 5 Sep 2018 at 15:54, Dave Tonge  
> 
> wrote:
>
>
> Hi Samuel,
>
> Thanks for the reply, I would definitely be interested in an updated
> draft.
> Both the signing spec and the canonicalization spec seem a lot simpler
> than JSON-LD.
> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>
> Thanks
>
> Dave
>
> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  
>  wrote:
>
>
> Hi
>
> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
> think this is the way to go. The initial use case was to sign transaction
> requests and responses, and as was mentioned in previous emails it is very
> much desirable to not obfuscate the payload with base64 encoding.
>
> The current draft just expired but if we have found interest I would be
> more than willing to post an update. I was supposed to do so earlier but
> since it has been hard to find a home for the work (an interested WG) it
> has not be top of my proirity list.
>
> With the potential update we (I and the co authors) intended to do some
> cleanup and one significant change. We think we should move from ES6
> serialization to canonicalization based on draft-rundgren-json-
> canonicalization-scheme
> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01> 
> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
> After a lot of research and emails we have come to the conclusion that it
> would be easier to get buy in for this method than to get languages to
> support ES6 compatible serialization. 
> draft-rundgren-json-canonicalization-scheme
> has the additional benefit that non-intrusive modifications such as
> attribute reordering would not make ruin this signature which was the case
> with ES6 serialization (and we could avoid some minor ES6 quirks).
>
> Implementations for the draft-rundgren-json-canonicalization-scheme
> canonicalization schema is available in 
> JavaScript<https://www.npmjs.com/package/canonicalize> 
> <https://www.npmjs.com/package/canonicalize>, 
> .NET<https://github.com/cyberphone/json-canonicalization/tree/master/dotnet> 
> <https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>,
> Java<https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>
>  
> <https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>,
> and 
> Python<https://github.com/cyberphone/json-canonicalization/tree/master/python3>
>  <https://github.com/cyberphone/json-canonicalization/tree/master/python3>.
> Anders is currently putting a lot of effort into the canonicalization to
> make sure it is stable, and it has been reviewed by several people
> knowledgeable in JSON.
>
> When it comes to draft-erdtman-jose-cleartext-jws implementations, I
> have done one in JavaScript (I modified an existing JOSE implementat

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Samuel Erdtman]

Thank you for asking Torsten,

If method or URL contains additional information not contained in the
request body then it would have to be duplicated into the request to be
signed. This may also aplie to headers.

I do not necessarily think it would be bad to duplicate this information
into the request. To support the non-repudiation use-case I expect the
request to be archived and then all this information must be stored. If we
had a schema that could sign method, URL, headers, and body independently
we would still need to collect them when archiving the full request. If we
instead duplicate this information in the request JSON it would be ready
for archiving and the information-format could be in the most appropriate
format for the application context.

With that said draft-erdtman-jose-cleartext-jws does not dictate a solution..

Best regards
//Samuel

On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt  wrote:

> Hi Samuel,
>
> thanks for preparing this draft. I‘ve got one question: how would one use
> it for non-reputation? I assume non-reputation would require not only to
> sign the request body but also (at least) data about the target of the
> request, typically a URL + HTTP method. Would one need to include
> (replicate) this data in the JSON object?
>
> kind regards,
> Torsten.
>
> Am 06.09.2018 um 22:20 schrieb Samuel Erdtman :
>
> Hi,
>
> A new version has been submitted. It would awesome if we could get some
> comments on the draft and thoughts about a potential future adoption.
>
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>
> Changes includes the change of canonicalization method and some minor
> clarifications.
>
> Best regards
> //Samuel
>
>
>
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrote:
>
>> Then I’ll post an update within a ~week.
>>
>> There is one thing that could make implementing even simpler (from my
>> experience). That is how to handle multiple signatures. Today the
>> specification supports sharing of headers between signatures. If signatures
>> instead are completely independent and put in an array at the top level
>> cleartext_signature attribute one could just do a minor change to existing
>> implementations to support cleartext signatures.
>>
>> On Wed, 5 Sep 2018 at 15:54, Dave Tonge 
>> wrote:
>>
>>> Hi Samuel,
>>>
>>> Thanks for the reply, I would definitely be interested in an updated
>>> draft.
>>> Both the signing spec and the canonicalization spec seem a lot simpler
>>> than JSON-LD.
>>> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>>>
>>> Thanks
>>>
>>> Dave
>>>
>>> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:
>>>
>>>> Hi
>>>>
>>>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
>>>> think this is the way to go. The initial use case was to sign transaction
>>>> requests and responses, and as was mentioned in previous emails it is very
>>>> much desirable to not obfuscate the payload with base64 encoding.
>>>>
>>>> The current draft just expired but if we have found interest I would be
>>>> more than willing to post an update. I was supposed to do so earlier but
>>>> since it has been hard to find a home for the work (an interested WG) it
>>>> has not be top of my proirity list.
>>>>
>>>> With the potential update we (I and the co authors) intended to do some
>>>> cleanup and one significant change. We think we should move from ES6
>>>> serialization to canonicalization based on
>>>> draft-rundgren-json-canonicalization-scheme
>>>> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
>>>> After a lot of research and emails we have come to the conclusion that it
>>>> would be easier to get buy in for this method than to get languages to
>>>> support ES6 compatible serialization. 
>>>> draft-rundgren-json-canonicalization-scheme
>>>> has the additional benefit that non-intrusive modifications such as
>>>> attribute reordering would not make ruin this signature which was the case
>>>> with ES6 serialization (and we could avoid some minor ES6 quirks).
>>>>
>>>> Implementations for the draft-rundgren-json-canonicalization-scheme
>>>> canonicalization schema is available in JavaScript
>>>> <https://www.npmjs.com/package/canonicalize>, .NET
>>>> <https://github.com/cyberphone/json-canonicalization/tree/master/dotnet

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Samuel Erdtman]

Then I’ll post an update within a ~week.

There is one thing that could make implementing even simpler (from my
experience). That is how to handle multiple signatures. Today the
specification supports sharing of headers between signatures. If signatures
instead are completely independent and put in an array at the top level
cleartext_signature attribute one could just do a minor change to existing
implementations to support cleartext signatures.
On Wed, 5 Sep 2018 at 15:54, Dave Tonge  wrote:

> Hi Samuel,
>
> Thanks for the reply, I would definitely be interested in an updated draft.
> Both the signing spec and the canonicalization spec seem a lot simpler
> than JSON-LD.
> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>
> Thanks
>
> Dave
>
> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:
>
>> Hi
>>
>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
>> think this is the way to go. The initial use case was to sign transaction
>> requests and responses, and as was mentioned in previous emails it is very
>> much desirable to not obfuscate the payload with base64 encoding.
>>
>> The current draft just expired but if we have found interest I would be
>> more than willing to post an update. I was supposed to do so earlier but
>> since it has been hard to find a home for the work (an interested WG) it
>> has not be top of my proirity list.
>>
>> With the potential update we (I and the co authors) intended to do some
>> cleanup and one significant change. We think we should move from ES6
>> serialization to canonicalization based on
>> draft-rundgren-json-canonicalization-scheme
>> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
>> After a lot of research and emails we have come to the conclusion that it
>> would be easier to get buy in for this method than to get languages to
>> support ES6 compatible serialization.
>> draft-rundgren-json-canonicalization-scheme has the additional benefit that
>> non-intrusive modifications such as attribute reordering would not make
>> ruin this signature which was the case with ES6 serialization (and we could
>> avoid some minor ES6 quirks).
>>
>> Implementations for the draft-rundgren-json-canonicalization-scheme
>> canonicalization schema is available in JavaScript
>> <https://www.npmjs.com/package/canonicalize>, .NET
>> <https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>,
>> Java
>> <https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>,
>> and Python
>> <https://github.com/cyberphone/json-canonicalization/tree/master/python3>.
>> Anders is currently putting a lot of effort into the canonicalization to
>> make sure it is stable, and it has been reviewed by several people
>> knowledgeable in JSON.
>>
>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
>> done one in JavaScript (I modified an existing JOSE implementation in a few
>> hours) and Anders has done a Java implementation (at least). The examples
>> in the specification was created and validated with different
>> implementations.
>>
>> I know canonicalization is a scary thing if you have worked with
>> canonicalization of XML, but I can tell you canonicalization of JSON is not
>> even close to that complex.
>>
>> Best regards
>> //Samuel Erdtman
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Samuel Erdtman]

Hi

As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
think this is the way to go. The initial use case was to sign transaction
requests and responses, and as was mentioned in previous emails it is very
much desirable to not obfuscate the payload with base64 encoding.

The current draft just expired but if we have found interest I would be
more than willing to post an update. I was supposed to do so earlier but
since it has been hard to find a home for the work (an interested WG) it
has not be top of my proirity list.

With the potential update we (I and the co authors) intended to do some
cleanup and one significant change. We think we should move from ES6
serialization to canonicalization based on
draft-rundgren-json-canonicalization-scheme
<https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
After a lot of research and emails we have come to the conclusion that it
would be easier to get buy in for this method than to get languages to
support ES6 compatible serialization.
draft-rundgren-json-canonicalization-scheme has the additional benefit that
non-intrusive modifications such as attribute reordering would not make
ruin this signature which was the case with ES6 serialization (and we could
avoid some minor ES6 quirks).

Implementations for the draft-rundgren-json-canonicalization-scheme
canonicalization schema is available in JavaScript
<https://www.npmjs.com/package/canonicalize>, .NET
<https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>, Java
<https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>,
and Python
<https://github.com/cyberphone/json-canonicalization/tree/master/python3>.
Anders is currently putting a lot of effort into the canonicalization to
make sure it is stable, and it has been reviewed by several people
knowledgeable in JSON.

When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
done one in JavaScript (I modified an existing JOSE implementation in a few
hours) and Anders has done a Java implementation (at least). The examples
in the specification was created and validated with different
implementations.

I know canonicalization is a scary thing if you have worked with
canonicalization of XML, but I can tell you canonicalization of JSON is not
even close to that complex.

Best regards
//Samuel Erdtman








On Mon, Sep 3, 2018 at 3:09 PM, Vladimir Dzhuvinov 
wrote:

> Hi George,
>
> JSON-LD still requires c14n. I opened the particular spec and the c14n job
> with JSON-LD appears quite complex. The structure of the linked data must
> also be brought into some particular form.
>
> https://json-ld.github.io/normalization/spec/
>
> C10n of plain JSON should be a simpler job. There should also be more and
> better software support for that. I don't think we can get around JSON
> c10n, if we want to keep the message content in clear text.
>
> Vladimir
>
> On 03/09/18 15:27, George Fletcher wrote:
>
> I'm not a big fan of canonicalization for signatures. In the past it has
> been brittle, the libraries subject to bugs, and hard for developers to
> adopt. That said, if no canonicalization is not a requirement, have you
> checked out JSON-LD? It has embedded signature support.
> https://json-ld.org/spec/latest/
>
> On 9/3/18 6:23 AM, Dave Tonge wrote:
>
> Hi Phil
>
> Thanks again for the helpful reply.
> I 100% agree with you about the problem of false negatives with RFC3230.
> I am not in favour of the its use and will do my best to highlight these
> issues with those who are proposing its use with the draft cavage spec.
>
> I also share your worry about the potential for things to move back to a
> SOAP style of API.
>
> Having a look at the https://tools.ietf.org/html/dr
> aft-ietf-oauth-signed-http-request-03 spec it is quite general purpose,
> whereas I'm in favour of something that is explicitly designed for JSON
> requests and responses. If there was confidence in the
> JSON canonicalisation described in https://tools.ietf.org/html/dr
> aft-erdtman-jose-cleartext-jws-00 then this seems to enable APIs to stay
> REStful but with the support for self-contained signatures. For many
> applications I agree that there will need to be some repetition of values
> in the JSON payload that are already in the header, e.g. audience, issuer
> and time. But if general purpose HTTP signing is a lost cause, then
> "Cleartext JSON Web Signatures" seem the next best thing.
>
> Dave
>
>
>
>
>
>
> On Sat, 1 Sep 2018 at 01:06, Phil Hunt  <mailto:phil.h...@oracle.com> > wrote:
>
> Dave,
>
> I’m not sure this is as useful as one might think - from RFC3230…
>
>
>
> 7 <https://tools.ietf.org/html/rfc3230#section-7>
>

Re: [OAUTH-WG] [Ace] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution

[Samuel Erdtman]

Hi Hannes,

Has there been any updates to draft-ietf-oauth-pop-key-distribution? I
could not find any updated document.

Best regards
//Samuel

On Fri, Jul 20, 2018 at 7:46 PM, Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi all,
>
>
>
> after several discussions we believe that we now have a proposal for
> moving forward on this topic.
>
> We plan to update the expired draft 
> and
>
> (1) remove the audience parameter and replace it with a
> separately-specified resource parameter,
>
> (2) remove the alg parameter,
>
> (3) update the procedures for requesting and obtaining keying material,
>
> (4) Synchronize with the ACE and WebRTC work to make sure that their use
> cases are appropriately covered.
>
>
>
> Regarding (1): The meeting participants have decided to standardize an
> audience-alike parameter (in the form of a requested resource identifier)
> at this weeks IETF OAuth meeting. For that purpose, working group adoption
> of draft-campbell-oauth-resource-indicators is under way.  Only a
> reference to that document will be needed.
>
>
>
> Regarding (2): Removal of the alg parameter will simplify the document and
> does not appear to be necessary for the currently investigated use cases.
> This assumption will have to be verified.
>
>
>
> Regarding (3): Currently, the ACE-OAuth document and the
>  use different parameter names.
> Furthermore, those parameter names may be in conflict with other, already
> standardized parameter names. Hence, some parameters may need to be
> renamed. The plan is to focus on the following, minimal functionality only:
> server-side symmetric key generation and client-side public key
> registration to the AS. Furthermore, the encoding of the key transport will
> have to take the different token formats and protocols into account.
>
>
>
> This approach will allow the ACE and WebRTC work to reference the generic
> PoP key distribution document without having to specify their own duplicate
> functionality.
>
>
>
> We are planning to update  next
> week to have something to review.
>
>
>
> Ciao
>
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414

[Samuel Erdtman]

Well done!

On Fri, Jun 29, 2018 at 2:12 AM, David Blevins 
wrote:

> I'm a new face, but did want to say congratulations to all.  It's great to
> see this movement into the OAuth 2.0 umbrella.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> On Jun 28, 2018, at 3:54 PM, Mike Jones  c...@dmarc.ietf.org> wrote:
>
> The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414
> .  The abstract describes the
> specification as:
>
> This specification defines a metadata format that an OAuth 2.0 client can
> use to obtain the information needed to interact with an OAuth 2.0
> authorization server, including its endpoint locations and authorization
> server capabilities.
>
> The specification defines a JSON metadata representation for OAuth 2.0
> authorization servers that is compatible with OpenID Connect Discovery 1.0
> .  This
> specification is a true instance of standardizing existing practice.  OAuth
> 2.0 deployments have been using the OpenID Connect metadata format to
> describe their endpoints and capabilities for years.  This RFC makes this
> existing practice a standard.
>
> Having a standard OAuth metadata format makes it easier for OAuth clients
> to configure connections to OAuth authorization servers.  See
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#
> authorization-server-metadata
> 
>  for the initial set of registered metadata values.
>
> Thanks to all of you who helped make this standard a reality!
>
>-- Mike
>
> P.S.  This announcement was also posted at http://self-issued.info/?p=1883
>  and as @selfissued .
>
> ___
> 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] review of draft-ietf-oauth-mtls-08

[Samuel Erdtman]

Hi

Thanks for a great document. I have some minor comments.

in Abstract
“...based on either single certificates...”
Why not write self-signed certificates, to me that is easier to understand,
and is the term that is used later in the document.

What is the rational behind writing “OAuth protected resources” or just “a
protected resource” instead of resource server? The term resource server is
user later in the document.

4.1.  Authorization Server
Is it not mandatory for the AS to not do PKI validation of self signed
certificates i.e. the following sentence, “it should configure the TLS
stack in a way”, should be changed to “it must configure the TLS stack in a
way”?

Finally it might make sense to mention the relation of this document to
RFC7521, RFC7522 and RFC7523. RFC7521 defines a client credentials
framework and the other two are examples of profiles. It also mentions
proof-of-possession. Maybe as an appendix similar to "Relationship to Token
Binding"

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

Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth

[Samuel Erdtman]

I support the adoption of *Reciprocal OAuth* as a WG document

On Mon, Apr 16, 2018 at 5:19 PM, Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi all,
>
> we had gotten positive feedback from the group on Reciprocal OAuth at the
> virtual interim meeting earlier this year and also at the London IETF
> meeting.
>
> We would therefore like to get a final confirmation on the mailing list
> for the adoption of the *Reciprocal OAuth* as a WG document
> https://tools.ietf.org/html/draft-hardt-oauth-mutual-02
>
> Please, let us know if you support or object to the adoption of this
> document by April 25th.
>
> Ciao
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> 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] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Samuel Erdtman]

Hi,

Adding an additional proposal to the table. Mike Jones, Anders Rundgren and
I have created a version of JWS there the signed JSON data does not have to
be Base64url encoded (the JSON is signed using ES6 serialization rules).
One of the benefits to this approach would be that the introspection data
is transferred in cleartext while still fully protected. Since it is
transferred in the response body and not in a URL there is no need for the
Base64url encoding.

The draft can be fond here
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00

And the example from your draft would look like this (the signature is not
valid, I just copied it from another place)
{
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource;,
  "extension_field": "twenty-seven",
  "scope": "read write dolphin",
  "iss": "https://server.example.com/;,
  "active": true,
  "exp": 1419356238,
  "iat": 1419350238,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe"
  "__cleartext_signature": {
"alg": "ES256",
"kid": "example.com:p256",
"signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI
  AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHHZjsYdT96JZw"
  }
}




On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt  wrote:

> +1.  This is what I expected.
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt 
> wrote:
>
> We explicitly want the token (JSON object) to be signed not the HTTP
> response. I think using JWS is the most generic way to achieve that goal.
>
> Am 19.03.2018 um 09:57 schrieb Phil Hunt :
>
> This draft has similar issues to https://tools.ietf.org/
> html/draft-richer-oauth-signed-http-request-01
>
> Rather than *try* sign HTTP, a signed JWT object is more reliably returned.
>
> Phil
>
>
> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis <
> louis.larmig...@wavestone.com> wrote:
>
> Hi,
>
> The draft *Signing HTTP Messages** 
> (https://tools.ietf.org/html/draft-cavage-http-signatures-09
> )* could not
> meet this requirement in a more generic way ?
>
> Regards,
> Louis
>
> *De :* OAuth  *De la part de* Brock Allen
> *Envoyé :* dimanche 18 mars 2018 20:40
> *À :* Torsten Lodderstedt ; oauth@ietf.org
> *Objet :* Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>
> Why is TLS to the intospection endpoint not sufficient? Are you thinking
> there needs to be some multi-tenancy support of some kind?
>
> -Brock
>
>
> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt 
> wrote:
> Hi all,
>
> I just submitted a new draft that Vladimir Dzhuvinov and I have written.
> It proposes a JWT-based response type for Token Introspection. The
> objective is to provide resource servers with signed tokens in case they
> need cryptographic evidence that the AS created the token (e.g. for
> liability).
>
> I will present the new draft in the session on Wednesday.
>
> kind regards,
> Torsten.
>
>
> Anfang der weitergeleiteten Nachricht:
>
> *Von: *internet-dra...@ietf.org
> *Betreff: New Version Notification for
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt*
> *Datum: *18. März 2018 um 20:19:37 MEZ
> *An: *"Vladimir Dzhuvinov" , "Torsten
> Lodderstedt" 
>
>
>
> A new version of I-D, draft-lodderstedt-oauth-jwt-
> introspection-response-00.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
>
> Name:   draft-lodderstedt-oauth-jwt-introspection-response
> Revision: 00
> Title:  JWT Response for OAuth Token Introspection
> Document date:  2018-03-15
> Group:  Individual Submission
> Pages:  5
> URL:https://www.ietf.org/internet-drafts/draft-
> lodderstedt-oauth-jwt-introspection-response-00.txt
> Status: https://datatracker.ietf.org/doc/draft-
> lodderstedt-oauth-jwt-introspection-response/
> Htmlized:   https://tools.ietf.org/html/draft-lodderstedt-oauth-
> jwt-introspection-response-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-
> lodderstedt-oauth-jwt-introspection-response
> 
>
>
> Abstract:
>   This draft proposes an additional JSON Web Token (JWT) based response
>   for OAuth 2.0 Token Introspection.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> The information transmitted in the present email including the attachment
> is intended only for the person to whom or entity to which it is addressed
> 

[OAUTH-WG] Fwd: New Version Notification for draft-erdtman-oauth-rpcc-00.txt

[Samuel Erdtman]

Hi,

I have submitted draft-erdtman-oauth-rpcc under the OAuth WG as discussed
during IETF 100. (Moved from ACE WG since the new credentials does not have
any formal connection to the ACE documents, i.e. pure OAuth stuff)

This document defines how to user Raw-Public-Key and Pre-Shared-Key with
(D)TLS as client credentials.

We think it is essential to define this for IoT devices since the classic
client id and secret is not very suitable for devices with limited user
interfaces.

Comments, questions and reviews would be very appreciated.

Cheers
//Samuel

-- Forwarded message -
From: <internet-dra...@ietf.org>
Date: Tue, 21 Nov 2017 at 11:09
Subject: New Version Notification for draft-erdtman-oauth-rpcc-00.txt
To: Marco Tiloca <marco.til...@ri.se>, Ludwig Seitz <ludwig.se...@ri.se>,
Samuel Erdtman <erdt...@spotify.com>



A new version of I-D, draft-erdtman-oauth-rpcc-00.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.

Name:   draft-erdtman-oauth-rpcc
Revision:   00
Title:  Raw-Public-Key and Pre-Shared-Key as OAuth client
credentials
Document date:  2017-11-20
Group:  Individual Submission
Pages:  6
URL:https://www.ietf.org/internet-drafts/draft-erdtman-oauth-
rpcc-00.txt
Status: https://datatracker.ietf.org/doc/draft-erdtman-oauth-rpcc/
Htmlized:   https://tools.ietf.org/html/draft-erdtman-oauth-rpcc-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-erdtman-oauth-
rpcc-00


Abstract:
   This document describes Transport Layer Security (TLS) authentication
   using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth
   client authentication.  Although defined for TLS the mechanisms are
   equally applicable for DTLS.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

Re: [OAUTH-WG] Review of draft-ietf-oauth-device-flow-06

[Samuel Erdtman]

Ping

On Thu, Sep 7, 2017 at 10:11 PM, Samuel Erdtman <sam...@erdtman.se> wrote:

> Hi Authors
>
> Thanks for writing this very useful draft.
>
> I have some review comments that I hope will be useful.
>
> As a general comment, has it been considered to include CoAP mappings too?
> it might be good to reach even more constrained devices (maybe another
> draft).
>
>
> 1.  Introduction
> Missing newline between Step E and D
>
> 1.  Introduction
> The bullet list with the polling of the client and the user authorisation
> is a bit hard to read, step D comes again after E. Maybe it would be easier
> to read if using decimal numbers.
>
> ‘1.  Introduction’ and ‘3.  Protocol’
> I would like to move the ascii art and the corresponding list of steps
> from ‘1.  Introduction’ to ‘3.  Protocol’ and use the terminology explained
> in ‘2.  Terminology’
>
> 3.1.  Device Authorization Request
> Is there no authentication? e.g. use of client secret? (or Pre-Shared Key
> or Raw Public key as described in draft-erdtman-ace-rpcc)
> I don’t think client identification is enough I think it should
> authenticate, at least as the recommendation.
>
> 3.2.  Device Authorization Response
> I would like to change verification_uri be optional. If for example the
> device vendor has a companion app that app could easily have the
> verification_uri, that would simplify for the user that would only have to
> enter the code. (and it could save some bytes).
>
> 3.2.  Device Authorization Response
> I think it would make sense to add an optional parameter with the token
> endpoint uri, in that way it does not have to be hardcoded in the client
> (or discovered) but the AS can tell the client where to get the token. Or
> it could be done with a redirect to the token URL or the Device
> Verification Code could be a the URL to poll instead.
>
> 3.4.  Device Access Token Request
> client_id, it says REQUIRED but then it states that it is to be used only
> if “client is not authenticating with the authorization server as described
> in Section 3.2.1. of [RFC6749].”
> I think the parameter should be optional and authentication required.
>
> 3.2.  Device Authorization Response and  3.5.  Device Access Token Response
> “The interval at which the client polls MUST NOT be more frequent than
>the "interval" parameter returned in the Device Authorization
>Response (see Section 3.2).”
> “OPTIONAL.  The minimum amount of time in seconds that the client
>   SHOULD wait between polling requests to the token endpoint.”
> Feels like a contradiction between the parameter description and token
> endpoint response. I would like to have MUST in both cases.
>
> 3.5.  Device Access Token Response
> I think last paragraph is better suited in the introduction section.
>
> 5.2.  Device Trustworthiness
> I think device authentication should/could be mentioned here
>
>
>
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] ACE and OAuth Extensions Error Registry

[Samuel Erdtman]

Hi Hannes and Dick,

In the work with the ACE framework (
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-07) that is based on
the OAuth framework I noticed that non of the error response codes
described in the OAuth Framework is IANA registered.
I could find invalid_request, unauthorized_client, access_denied,
unsupported_response_type, invalid_scope, server_error,
temporarily_unavailable, invalid_client, invalid_grant by scrolling through
the RFC but only a few of them are registered via other RFCs/specifications.

Is there a reason for not including these in the IANA registry for OAuth
Extensions Error Registry? Is there another registry for these?

In the ACE framework we want to map these to integers to save some precious
bytes.

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

[OAUTH-WG] Review of draft-ietf-oauth-device-flow-06

[Samuel Erdtman]

Hi Authors

Thanks for writing this very useful draft.

I have some review comments that I hope will be useful.

As a general comment, has it been considered to include CoAP mappings too?
it might be good to reach even more constrained devices (maybe another
draft).


1.  Introduction
Missing newline between Step E and D

1.  Introduction
The bullet list with the polling of the client and the user authorisation
is a bit hard to read, step D comes again after E. Maybe it would be easier
to read if using decimal numbers.

‘1.  Introduction’ and ‘3.  Protocol’
I would like to move the ascii art and the corresponding list of steps from
‘1.  Introduction’ to ‘3.  Protocol’ and use the terminology explained in
‘2.  Terminology’

3.1.  Device Authorization Request
Is there no authentication? e.g. use of client secret? (or Pre-Shared Key
or Raw Public key as described in draft-erdtman-ace-rpcc)
I don’t think client identification is enough I think it should
authenticate, at least as the recommendation.

3.2.  Device Authorization Response
I would like to change verification_uri be optional. If for example the
device vendor has a companion app that app could easily have the
verification_uri, that would simplify for the user that would only have to
enter the code. (and it could save some bytes).

3.2.  Device Authorization Response
I think it would make sense to add an optional parameter with the token
endpoint uri, in that way it does not have to be hardcoded in the client
(or discovered) but the AS can tell the client where to get the token. Or
it could be done with a redirect to the token URL or the Device
Verification Code could be a the URL to poll instead.

3.4.  Device Access Token Request
client_id, it says REQUIRED but then it states that it is to be used only
if “client is not authenticating with the authorization server as described
in Section 3.2.1. of [RFC6749].”
I think the parameter should be optional and authentication required.

3.2.  Device Authorization Response and  3.5.  Device Access Token Response
“The interval at which the client polls MUST NOT be more frequent than
   the "interval" parameter returned in the Device Authorization
   Response (see Section 3.2).”
“OPTIONAL.  The minimum amount of time in seconds that the client
  SHOULD wait between polling requests to the token endpoint.”
Feels like a contradiction between the parameter description and token
endpoint response. I would like to have MUST in both cases.

3.5.  Device Access Token Response
I think last paragraph is better suited in the introduction section.

5.2.  Device Trustworthiness
I think device authentication should/could be mentioned here
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK

[Samuel Erdtman]

In short this draft focuses on the C to AS connection and
draft-gerdes-ace-dtls-authorize focuses on the C to RS connection.

This draft details on how to use RPK or PSK as client credentials to setup
the (D)TLS between C and AS while draft-gerdes-ace-dtls-authorize provides
details for how to use the RPK or PSK bound to an access token to setup the
connection between C and RS.

//Samuel


On Sun, May 14, 2017 at 10:18 PM, Jim Schaad <i...@augustcellars.com> wrote:

> How is this draft supposed to interact with draft-gerdes-ace-dtls-
> authorize?
>
>
>
> Jim
>
>
>
>
>
> *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Samuel Erdtman
> *Sent:* Friday, May 12, 2017 1:03 AM
> *To:* <oauth@ietf.org> <oauth@ietf.org>; ace <a...@ietf.org>
> *Cc:* Ludwig Seitz <ludwig.se...@ri.se>
> *Subject:* [Ace] New OAuth client credentials RPK and PSK
>
>
>
> Hi ACE and OAuth WGs,
>
> I and Ludwig submitted a new draft yesterday defining how to use Raw
> Public Key and Pre Shared Key with (D)TLS as OAuth client credentials,
> https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.
>
>
>
> We think this is valuable to the ACE work since the ACE framework is based
> on OAuth, but client credentials as defined in the OAuth framework are not
> the best match for embedded devices.
>
> We think Raw Public Keys and Pre Shared Keys are more suitable credentials
> for embedded devices for the following reasons:
>
> * Better security by binding to transport layer.
>
> * If PSK DTLS is to be used a key need to be distributed any way, why not
> make use of it as credential.
>
> * Client id and client secret accommodates for manual input by a humans.
> This does not scale well and requires some for of input device.
>
> * Some/many devices will have crypto-hardware that can protect key
> material, to not use that possibility would be a waste.
>
> * There are probably more reasons these was just the once on top of my
> head.
>
>
>
> This is not the first resent initiative to create new client credential
> types, the OAuth WG adopted a similar draft for certificate based client
> credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html).
> That work is also valuable to ACE but not all devices will be able to work
> with certificates or even asymmetric cryptos .
>
> Please review and comment.
>
> Cheers
>
> //Samuel
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New OAuth client credentials RPK and PSK

[Samuel Erdtman]

Hi Torsten,

That is a possibility, I excluded it to keep the scope limited and because
I don´t think it is as applicable with these credential types.

I think these credential types will mostly be used in IoT deployments using
the ACE framework, in that case the token will have its own key that will
most likely be used in the (D)TLS handshake between the client and resource
server see e.g.
https://tools.ietf.org/html/draft-gerdes-ace-dtls-authorize-01.

However if the token would not be a PoP token then it could make sense. Do
you fore see such use cases where it would be useful?

One thing that I did not mention in my earlier email that could be a
possible path forward would be to merge this draft into the mtls one.

//Samuel


On Sat, May 13, 2017 at 11:58 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Samuel,
>
> as far as I understand your draft, it utilizes results of the (D)TLS
> client authentication for authentication towards the tokens endpoint -
> similar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do
> you intend to also utilize the binding of the access token to a certain key
> pair as described in oauth-ietf-mtls?
>
> best regards,
> Torsten.
>
> Am 12.05.2017 um 10:03 schrieb Samuel Erdtman <sam...@erdtman.se>:
>
> Hi ACE and OAuth WGs,
>
> I and Ludwig submitted a new draft yesterday defining how to use Raw
> Public Key and Pre Shared Key with (D)TLS as OAuth client credentials,
> https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.
>
> We think this is valuable to the ACE work since the ACE framework is based
> on OAuth, but client credentials as defined in the OAuth framework are not
> the best match for embedded devices.
>
> We think Raw Public Keys and Pre Shared Keys are more suitable credentials
> for embedded devices for the following reasons:
> * Better security by binding to transport layer.
> * If PSK DTLS is to be used a key need to be distributed any way, why not
> make use of it as credential.
> * Client id and client secret accommodates for manual input by a humans.
> This does not scale well and requires some for of input device.
> * Some/many devices will have crypto-hardware that can protect key
> material, to not use that possibility would be a waste.
> * There are probably more reasons these was just the once on top of my
> head.
>
> This is not the first resent initiative to create new client credential
> types, the OAuth WG adopted a similar draft for certificate based client
> credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html).
> That work is also valuable to ACE but not all devices will be able to work
> with certificates or even asymmetric cryptos .
>
> Please review and comment.
>
> Cheers
> //Samuel
>
>
> ___
> 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] 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] review draft-ietf-oauth-native-apps-07

[Samuel Erdtman]

Thanks Denis!

On Fri, Mar 3, 2017 at 7:37 AM, William Denniss <wdenn...@google.com> wrote:

> Thanks all for the great discussion. I tweaked the discussion on
> public/confidential clients to rely more on the OAuth2 definition (it was a
> bit duplicative), and I reordered the security considerations so it flows
> better, but have kept the normative language for now. Let's see how it pans
> out during the finalization process.
>
> On Mon, Feb 27, 2017 at 8:47 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>> Thanks for the replies.
>>
>> If there are no formal guidelines from IETF I think we should just
>> proceed it is a good and informative spec, it was just to me it felt
>> slightly of.
>>
>> Based on the conversation I have no objections taking this draft to RFC.
>>
>> //Samuel
>>
>> On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer <jric...@mit.edu> wrote:
>>
>>> When I brought RFCs 7591, 7592, and 7662 up through the finalization
>>> process, I learned that there are two camps out there on normative
>>> requirements in the security considerations section. Some like them, as
>>> long as they don’t contradict requirements/advice in previous sections, and
>>> some don’t like them, preferring all normative material be in the “body” of
>>> the spec itself. I was given the impression that it was more of a stylistic
>>> choice than anything, but I can only speak from my personal experience.
>>>
>>>  — Justin
>>>
>>> On Feb 21, 2017, at 3:17 PM, William Denniss <wdenn...@google.com>
>>> wrote:
>>>
>>> The only real requirement in that section I guess is the use of PKCE
>>> (8.2).  That requirement could be moved to the body of the doc, while
>>> keeping the longer discussing around code interception in the security
>>> considerations.  To me the remaining text are indeed security best
>>> practices / clarifications.
>>>
>>> Other OAuth WG RFCs have requirement level capitalization in the
>>> Security Section like RFC7591. I always assumed these were best-practice
>>> security requirements. But if the style is really not to do this, the
>>> requirement level capitalization could be dropped from that section in the
>>> native apps BCP.
>>>
>>> On Tue, Feb 21, 2017 at 12:50 AM, Denis <denis.i...@free.fr> wrote:
>>>
>>>>
>>>> I *don't thin**k* it's normal to have normative text in the Security
>>>> Considerations, hence I support Samuel's position.
>>>>
>>>> Let us look at the first MUST from RFC 6749 in the Security
>>>> Considerations section:
>>>>
>>>>The authorization server *MUST *authenticate the client *whenever 
>>>> possible*.
>>>> This sentence is incorrect. The right sentence should be :
>>>>
>>>>The authorization server *should *authenticate the client whenever 
>>>> possible.
>>>>
>>>> RFC 6749 is not an example to follow.
>>>>
>>>> Denis
>>>>
>>>>
>>>> I do think it's normal to have normative text in the Security
>>>> Considerations.  RFC6749 has a lengthy Security Considerations section
>>>> <https://tools.ietf.org/html/rfc6749#section-10> with a lot of
>>>> normative text.
>>>>
>>>> Think of it this way: Sections 4 to 7 describe how to use native app
>>>> URI schemes to perform OAuth flows from the app to browser and back. If you
>>>> only read those sections, you could have a functioning (but potentially
>>>> insecure) OAuth flow in a native app. The security section adds some
>>>> security requirements and clarifications for implementing Sections 4-7,
>>>> like using PKCE, and more.
>>>>
>>>> Reviewing sub-section by sub-section:
>>>>
>>>> 8.1 Definitely belongs here, as the the whole BCP is about native-app
>>>> URI schemes, whereas doing OAuth in a WebView doesn't need those (as the
>>>> client can just pluck out the code from any redirect URI)
>>>> 8.2 Requires that servers who want to follow the native apps BCP
>>>> support PKCE, and recommends that they reject requests from clients who
>>>> don't.  This *could* be in the main doc, but since PKCE is an existing
>>>> thing, and is purely additive from a security perspective, I think this
>>>> reference works fine. Originally I talked about PKCE more in the doc body,
>>>> 

Re: [OAUTH-WG] SPA applications best practice

[Samuel Erdtman]

Hi Jim,

If there is enough information I think such RFC could be interesting in the
same way as  "OAuth 2.0 for Native Apps" (
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07) is for native
app.

To see if the group also thinks so I would suggest to create a personal
draft and ask it to be adopted as a working group item. (I´ll send you a
direct message with some details on how to do that)

Best Regards
Samuel Erdtman


On Mon, Feb 27, 2017 at 3:17 PM, Jim Manico <j...@manicode.com> wrote:

> I've been collecting opinions about the best OAuth2 workflows for SPA
> applications and have come up with the following basic recommendations.
>
> 1) The more secure flow is going to be authorization code. Keep access
> tokens out of the DOM/Browser history.
>
> 2) Implicit flows are your only choice if you allow serverless JS clients
> to access your OAuth endpoints. This is much easier to implement but
> carries a great deal more risk. Wether or not this is good for you depends
> on your threat model and risk tolerance.
>
> I'd love to keep going and turn this into a RFC but this is over my head.
> Does anyone here with more experience care to assist in proposing a
> SPA-OAuth RFC? I'd be happy to help with the grunt work. This is one of the
> main areas of OAuth where answers are fractured and I'd love to help push
> more clarity here.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> ___
> 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] review draft-ietf-oauth-native-apps-07

[Samuel Erdtman]

Thanks for the replies.

If there are no formal guidelines from IETF I think we should just proceed
it is a good and informative spec, it was just to me it felt slightly of.

Based on the conversation I have no objections taking this draft to RFC.

//Samuel

On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer <jric...@mit.edu> wrote:

> When I brought RFCs 7591, 7592, and 7662 up through the finalization
> process, I learned that there are two camps out there on normative
> requirements in the security considerations section. Some like them, as
> long as they don’t contradict requirements/advice in previous sections, and
> some don’t like them, preferring all normative material be in the “body” of
> the spec itself. I was given the impression that it was more of a stylistic
> choice than anything, but I can only speak from my personal experience.
>
>  — Justin
>
> On Feb 21, 2017, at 3:17 PM, William Denniss <wdenn...@google.com> wrote:
>
> The only real requirement in that section I guess is the use of PKCE
> (8.2).  That requirement could be moved to the body of the doc, while
> keeping the longer discussing around code interception in the security
> considerations.  To me the remaining text are indeed security best
> practices / clarifications.
>
> Other OAuth WG RFCs have requirement level capitalization in the Security
> Section like RFC7591. I always assumed these were best-practice security
> requirements. But if the style is really not to do this, the requirement
> level capitalization could be dropped from that section in the native apps
> BCP.
>
> On Tue, Feb 21, 2017 at 12:50 AM, Denis <denis.i...@free.fr> wrote:
>
>>
>> I *don't thin**k* it's normal to have normative text in the Security
>> Considerations, hence I support Samuel's position.
>>
>> Let us look at the first MUST from RFC 6749 in the Security
>> Considerations section:
>>
>>The authorization server *MUST *authenticate the client *whenever 
>> possible*.
>> This sentence is incorrect. The right sentence should be :
>>
>>The authorization server *should *authenticate the client whenever 
>> possible.
>>
>> RFC 6749 is not an example to follow.
>>
>> Denis
>>
>>
>> I do think it's normal to have normative text in the Security
>> Considerations.  RFC6749 has a lengthy Security Considerations section
>> <https://tools.ietf.org/html/rfc6749#section-10> with a lot of normative
>> text.
>>
>> Think of it this way: Sections 4 to 7 describe how to use native app URI
>> schemes to perform OAuth flows from the app to browser and back. If you
>> only read those sections, you could have a functioning (but potentially
>> insecure) OAuth flow in a native app. The security section adds some
>> security requirements and clarifications for implementing Sections 4-7,
>> like using PKCE, and more.
>>
>> Reviewing sub-section by sub-section:
>>
>> 8.1 Definitely belongs here, as the the whole BCP is about native-app URI
>> schemes, whereas doing OAuth in a WebView doesn't need those (as the client
>> can just pluck out the code from any redirect URI)
>> 8.2 Requires that servers who want to follow the native apps BCP support
>> PKCE, and recommends that they reject requests from clients who don't.
>> This *could* be in the main doc, but since PKCE is an existing thing, and
>> is purely additive from a security perspective, I think this reference
>> works fine. Originally I talked about PKCE more in the doc body, but some
>> reviewers thought it was then a little duplicative of the PKCE doc itself.
>> 8.3 This reads like classic security considerations to me, clarifying
>> some details of 7.3
>> 8.4 Part of this reads a little new-ish, regarding distinguishing native
>> clients from web ones. But on review, I think could just be re-worded to
>> reference RFC6749 Section 2.1.
>> 8.5 This one belongs where it is since the body of the BCP is talking
>> about the code flow.
>> 8.6 Totally belongs.
>> 8.7 to 8.11 belong IMO, they are security clarifications of long-standing
>> topics.
>>
>> My methodology when reviewing this was: is the text introducing a new
>> topic directly related to native apps or sections 4-7, or does it discuss
>> an old security topic in the context of native apps, or add security
>> related discussions of the content in 4-7. Of all those, I really only see
>> a bit of new topic related to native apps in 8.4, and in actual fact it
>> that sub-section should probably be reworded since RFC6749 already
>> establishes the public client type, which native apps are and a

[OAUTH-WG] review draft-ietf-oauth-native-apps-07

[Samuel Erdtman]

Hi,

I just had a question on best practice. In this document a large part of
the normative text is located under Security Considerations.

I had previously seen Security Considerations as things to think about when
implementing not so much as MUSTs and MUST NOTs.

I think it is okay to have it this way but it surprised me a bit and wanted
to ask if there is any best practice for the Security Considerations
section saying what type of information it should include.

Best Regards
Samuel Erdtman
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

+1 on providing guidance.


On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell <bcampb...@pingidentity.com
> wrote:

> Yes, I believe you are correct. Client certificates are provided in the
> handshake (initial or renegotiated) at the request of the server. If the
> server asks and the client doesn't provide a cert, it's up to the server
> whether to continue or about the handshake.
>
> There seem to be a number of different ways of trying to deal with this
> (not strictly for this OAuth case but similar situations).
>
> The AS could always request client certs but allow connections to proceed
> regardless. Then check for certs for appropriate clients while processing
> token requests.  I guess there's a little overhead in the handshake with
> this for all the connections that won't present a cert. But not a ton. The
> main drawback is that some/many browsers have UI that will prompt users to
> choose a cert even when they don't have any. And the user experience can be
> very bad or confusing as a result.
>
> The token endpoint could be on a different host or port which always
> requests client certs. Still allow connections to proceed regardless and
> check the client credentials at the OAuth layer. Pretty similar to the
> above but avoids the usability issues with end users because it's only at
> the token endpoint.
>
> Trying renegotiation after the application sees that it's a token request
> or that it's a token request from a client id that's configured for mutual
> TLS is another approach. In my own limited experience with this kind of
> thing, however, this approach can be kind of flaky. And your point about
> the initial data not being trustworthy is legitimate. I'm not sure if it
> really matters in this case. I don't know. And signaling to resubmit is
> another issue all together.
>
> There are probably other approaches too but those are the things I've seen
> or can imagine. In all (or nearly all) the deployments of our stuff that I
> know about that deal with mutual TLS, some variation of the second option
> is used.
>
> All this seem like implementation/deployment details though and I'm
> hesitant to try and define how to do it in this doc. Maybe providing some
> guidance. I'm not exactly sure how to do that though.
>
>
>
> On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman <sam...@erdtman.se>
> wrote:
>
>> Torstens questions triggers another question from me.
>>
>> If we have an AS that can handle both certificate client auth and client
>> secret, how does the AS know that it should ask for client certificate on
>> the TLS layer.
>>
>> It was a while since I last read the TLS specification and it might have
>> changed but if i remember correctly client certificates are provided in
>> initial handshake or in re-negotiate and it is only provided on request by
>> the server.
>>
>> If this is still true the AS would need to first get the token request,
>> see that this is a client that authenticates with certificate and request a
>> TLS re-negotiate to get the certificate authentication and a re-submission
>> of the token request since we cannot trust the data first submitted.
>>
>> Are I missing something obvious, or is this something that needs to be
>> defined?
>>
>> //Samuel
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jric...@mit.edu> wrote:
>>
>>> Right — this is a fine way to put it. RFC7591 defines a client model
>>> where RFC6749 didn’t. Ideally all that metadata would’ve been in the
>>> original spec, but it’s not. It doesn’t matter whether the client was
>>> registered dynamically or statically, it just matters that the AS knows
>>> what to expect from a given client.
>>>
>>>  — Justin
>>>
>>> On Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampb...@pingidentity.com>
>>> wrote:
>>>
>>> Yes, the intend is that the authentication method is determined by
>>> client policy regardless of whether the client was dynamically registered
>>> or statically configured or whatever. I can make that point more explicit
>>> in future revisions of the draft.
>>>
>>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <
>>> tors...@lodderstedt.net> wrote:
>>>
>>>> I understand. My point is different: the text seems to assume everybody
>>>> is using client registration, but that's not the case. I would like to
>>>> point out it makes sense to explicitely state the assumption that it is
>>>> determined by client policy (indepe

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

Torstens questions triggers another question from me.

If we have an AS that can handle both certificate client auth and client
secret, how does the AS know that it should ask for client certificate on
the TLS layer.

It was a while since I last read the TLS specification and it might have
changed but if i remember correctly client certificates are provided in
initial handshake or in re-negotiate and it is only provided on request by
the server.

If this is still true the AS would need to first get the token request, see
that this is a client that authenticates with certificate and request a TLS
re-negotiate to get the certificate authentication and a re-submission of
the token request since we cannot trust the data first submitted.

Are I missing something obvious, or is this something that needs to be
defined?

//Samuel







On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer  wrote:

> Right — this is a fine way to put it. RFC7591 defines a client model where
> RFC6749 didn’t. Ideally all that metadata would’ve been in the original
> spec, but it’s not. It doesn’t matter whether the client was registered
> dynamically or statically, it just matters that the AS knows what to expect
> from a given client.
>
>  — Justin
>
> On Nov 14, 2016, at 6:21 AM, Brian Campbell 
> wrote:
>
> Yes, the intend is that the authentication method is determined by client
> policy regardless of whether the client was dynamically registered or
> statically configured or whatever. I can make that point more explicit in
> future revisions of the draft.
>
> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> I understand. My point is different: the text seems to assume everybody
>> is using client registration, but that's not the case. I would like to
>> point out it makes sense to explicitely state the assumption that it is
>> determined by client policy (indepedent of the way this policy is
>> established).
>>
>>
>> Am 13.11.2016 um 14:24 schrieb Justin Richer:
>>
>> As part of the client’s registered data model. At least, based on how our
>> own implementation works (where we support client_secret_basic,
>> private_key_jwt, etc), that’s where we’d check to see if the client was
>> supposed to be using TLS auth or not.
>>
>> We don’t let clients switch away from their registered auth mechanism.
>>
>>  — Justin
>>
>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt 
>> wrote:
>>
>> Justin,
>>
>> Am 13.11.2016 um 13:39 schrieb Justin Richer:
>>
>> Torsten, I believe this is intended to be triggered by the
>> tls_client_auth value specified in §3.
>>
>>
>> in the token request?
>>
>>
>> Nit on that section, the field name for the client metadata in RFC7591 is
>> token_endpoint_auth_method, the _supported version is from the
>> corresponding discovery document.
>>
>>  — Justin
>>
>> Torsten.
>>
>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>> Hi John and Brian,
>>
>> thanks for writting this draft.
>>
>> One question: how does the AS determine the authentication method is TLS
>> authentication? I think you assume this is defined by the client-specific
>> policy, independent of whether the client is registered automatically or
>> manually. Would you mind to explicitely state this in the draft?
>>
>> best regards,
>> Torsten.
>>
>> Am 11.10.2016 um 05:59 schrieb John Bradley:
>>
>> At the request of the OpenID Foundation Financial Services API Working
>> group, Brian Campbell and I have documented
>> mutual TLS client authentication.   This is something that lots of people
>> do in practice though we have never had a spec for it.
>>
>> The Banks want to use it for some server to server API use cases being
>> driven by new open banking regulation.
>>
>> The largest thing in the draft is the IANA registration of
>> “tls_client_auth” Token Endpoint authentication method for use in
>> Registration and discovery.
>>
>> The trust model is intentionally left open so that you could use a
>> “common name” and a restricted list of CA or a direct lookup of the subject
>> public key against a reregistered value,  or something in between.
>>
>> I hope that this is non controversial and the WG can adopt it quickly.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> *From: * internet-dra...@ietf.org
>> *Subject: **New Version Notification for
>> draft-campbell-oauth-tls-client-auth-00.txt*
>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3
>> *To: *"Brian Campbell" < 
>> brian.d.campb...@gmail.com>, "John Bradley" < 
>> ve7...@ve7jtb.com>
>>
>>
>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
>> has been successfully submitted by John Bradley and posted to the
>> IETF repository.
>>
>> Name: draft-campbell-oauth-tls-client-auth
>> Revision: 00
>> Title: Mutual 

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

The reason I think it is a workaround to use the jwks or jwks_uri is that
you would then wrap the x5u, x5c and/or x5t in a jwk object that you do not
really need. So the implementation needs to be aware of how to create and
read jwk even though it will not use any of the jwk data.

With that said, lets see what others think.



On Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell <bcampb...@pingidentity.com
> wrote:

> From my point of view, the cleaner solution is using existing fields for
> what they are well suited rather than inventing new ones.
>
> On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>> You are right one could absolutely use the jwks or jwks_uri attribute,
>> but from my point of view that would be a workaround.
>> I would prefer that x5u, x5c and/or x5t was directly available in the
>> client registration request not via jwks. This would be a cleaner solution.
>>
>> Best Regards
>> Samuel
>>
>> On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampb...@pingidentity.com>
>> wrote:
>>
>>> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice?
>>> Perhaps some guidance in this document about that is warranted. But I don't
>>> believe anything new is needed for that case.
>>>
>>> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <sam...@erdtman.se> wrote:
>>>
>>> Just a quick comment, see inline
>>>
>>> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jric...@mit.edu> wrote:
>>>
>>> I agree that the client_id is unlikely to be found inside the
>>> certificate itself. The client_id is issued by the authorization server for
>>> the client to use at that single AS. The certificate is issued by the CA
>>> for the client to use on any connection. The AS and CA are not likely to be
>>> the same system in most deployments. The client will use the same cert
>>> across multiple connections, possibly multiple AS's, but the same isn't
>>> true of the client_id.
>>>
>>> Additionally, I think we want to allow for a binding of a self-signed
>>> certificate using dynamic registration, much the way that we already allow
>>> binding of a client-generated JWK today.
>>>
>>> Should this specification then extend the dynamic registration
>>> specification (https://tools.ietf.org/html/rfc7591) with the
>>> certificate parameter to actually do the registration or is that another
>>> document?
>>>
>>>
>>> I do think that more examples and guidance are warranted, though, to
>>> help AS developers.
>>>
>>>  -- Justin
>>>
>>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>>
>>>
>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se>
>>> wrote:
>>>
>>>
>>> I agree it is written so that the connection to the certificate is
>>> implicitly required but I think it would be better if it was explicit
>>> written since the lack of a connection would result in a potential security
>>> hole.
>>>
>>>
>>> That's fair. I agree it can be made more explicit and that it be good to
>>> do so.
>>>
>>>
>>>
>>> When it comes to the client_id I think subject common name or maybe
>>> subject serial numbers will be the common location, and I think an example
>>> would be valuable.
>>>
>>>
>>>
>>> In my experience and the way we built support for mutual TLS OAuth
>>> client auth the client_id value does not appear in the certificate
>>> anywhere. I'm not saying it can't happen but don't think it's particularly
>>> common.
>>>
>>> I can look at adding some examples, if there's some consensus that
>>> they'd be useful and this document moves forward.
>>>
>>>
>>>
>>>
>>> I´m not saying it is a bad Idea just that I would prefer if it was not a
>>> MUST.
>>> With very limited addition of code it is just as easy to get the
>>> certificate attribute for client id as it is to get it from the HTTP
>>> request data (at least in java). I also think that with the requirement to
>>> match the incoming certificate in some way one has to read out the
>>> certificate that was used to establish the connection to do some kind of
>>> matching.
>>>
>>>
>>> Getting data out of the certificate isn't a concern. I just believe that
>>> the constancy of having the client id parameter is worth the potential
>>> small amount duplicate data in some cases. It's just a -00 draft though and
>>> if the WG wants to proceed with this document, we seek further input and
>>> work towards some consensus.
>>>
>>>
>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

You are right one could absolutely use the jwks or jwks_uri attribute, but
from my point of view that would be a workaround.
I would prefer that x5u, x5c and/or x5t was directly available in the
client registration request not via jwks. This would be a cleaner solution.

Best Regards
Samuel

On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampb...@pingidentity.com>
wrote:

> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice?
> Perhaps some guidance in this document about that is warranted. But I don't
> believe anything new is needed for that case.
>
> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <sam...@erdtman.se> wrote:
>
> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jric...@mit.edu> wrote:
>
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by the authorization server for the client
> to use at that single AS. The certificate is issued by the CA for the
> client to use on any connection. The AS and CA are not likely to be the
> same system in most deployments. The client will use the same cert across
> multiple connections, possibly multiple AS's, but the same isn't true of
> the client_id.
>
> Additionally, I think we want to allow for a binding of a self-signed
> certificate using dynamic registration, much the way that we already allow
> binding of a client-generated JWK today.
>
> Should this specification then extend the dynamic registration
> specification (https://tools.ietf.org/html/rfc7591) with the certificate
> parameter to actually do the registration or is that another document?
>
>
> I do think that more examples and guidance are warranted, though, to help
> AS developers.
>
>  -- Justin
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>
> I agree it is written so that the connection to the certificate is
> implicitly required but I think it would be better if it was explicit
> written since the lack of a connection would result in a potential security
> hole.
>
>
> That's fair. I agree it can be made more explicit and that it be good to
> do so.
>
>
>
> When it comes to the client_id I think subject common name or maybe
> subject serial numbers will be the common location, and I think an example
> would be valuable.
>
>
>
> In my experience and the way we built support for mutual TLS OAuth client
> auth the client_id value does not appear in the certificate anywhere. I'm
> not saying it can't happen but don't think it's particularly common.
>
> I can look at adding some examples, if there's some consensus that they'd
> be useful and this document moves forward.
>
>
>
>
> I´m not saying it is a bad Idea just that I would prefer if it was not a
> MUST.
> With very limited addition of code it is just as easy to get the
> certificate attribute for client id as it is to get it from the HTTP
> request data (at least in java). I also think that with the requirement to
> match the incoming certificate in some way one has to read out the
> certificate that was used to establish the connection to do some kind of
> matching.
>
>
> Getting data out of the certificate isn't a concern. I just believe that
> the constancy of having the client id parameter is worth the potential
> small amount duplicate data in some cases. It's just a -00 draft though and
> if the WG wants to proceed with this document, we seek further input and
> work towards some consensus.
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

You are absolutely right one could use the

On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampb...@pingidentity.com>
wrote:

> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice?
> Perhaps some guidance in this document about that is warranted. But I don't
> believe anything new is needed for that case.
>
> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <sam...@erdtman.se> wrote:
>
> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jric...@mit.edu> wrote:
>
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by the authorization server for the client
> to use at that single AS. The certificate is issued by the CA for the
> client to use on any connection. The AS and CA are not likely to be the
> same system in most deployments. The client will use the same cert across
> multiple connections, possibly multiple AS's, but the same isn't true of
> the client_id.
>
> Additionally, I think we want to allow for a binding of a self-signed
> certificate using dynamic registration, much the way that we already allow
> binding of a client-generated JWK today.
>
> Should this specification then extend the dynamic registration
> specification (https://tools.ietf.org/html/rfc7591) with the certificate
> parameter to actually do the registration or is that another document?
>
>
> I do think that more examples and guidance are warranted, though, to help
> AS developers.
>
>  -- Justin
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>
> I agree it is written so that the connection to the certificate is
> implicitly required but I think it would be better if it was explicit
> written since the lack of a connection would result in a potential security
> hole.
>
>
> That's fair. I agree it can be made more explicit and that it be good to
> do so.
>
>
>
> When it comes to the client_id I think subject common name or maybe
> subject serial numbers will be the common location, and I think an example
> would be valuable.
>
>
>
> In my experience and the way we built support for mutual TLS OAuth client
> auth the client_id value does not appear in the certificate anywhere. I'm
> not saying it can't happen but don't think it's particularly common.
>
> I can look at adding some examples, if there's some consensus that they'd
> be useful and this document moves forward.
>
>
>
>
> I´m not saying it is a bad Idea just that I would prefer if it was not a
> MUST.
> With very limited addition of code it is just as easy to get the
> certificate attribute for client id as it is to get it from the HTTP
> request data (at least in java). I also think that with the requirement to
> match the incoming certificate in some way one has to read out the
> certificate that was used to establish the connection to do some kind of
> matching.
>
>
> Getting data out of the certificate isn't a concern. I just believe that
> the constancy of having the client id parameter is worth the potential
> small amount duplicate data in some cases. It's just a -00 draft though and
> if the WG wants to proceed with this document, we seek further input and
> work towards some consensus.
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jric...@mit.edu> wrote:

> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by the authorization server for the client
> to use at that single AS. The certificate is issued by the CA for the
> client to use on any connection. The AS and CA are not likely to be the
> same system in most deployments. The client will use the same cert across
> multiple connections, possibly multiple AS's, but the same isn't true of
> the client_id.
>
> Additionally, I think we want to allow for a binding of a self-signed
> certificate using dynamic registration, much the way that we already allow
> binding of a client-generated JWK today.
>
Should this specification then extend the dynamic registration
specification (https://tools.ietf.org/html/rfc7591) with the certificate
parameter to actually do the registration or is that another document?


> I do think that more examples and guidance are warranted, though, to help
> AS developers.
>
>  -- Justin
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>>
>> I agree it is written so that the connection to the certificate is
>> implicitly required but I think it would be better if it was explicit
>> written since the lack of a connection would result in a potential security
>> hole.
>>
>
> That's fair. I agree it can be made more explicit and that it be good to
> do so.
>
>
>
>> When it comes to the client_id I think subject common name or maybe
>> subject serial numbers will be the common location, and I think an example
>> would be valuable.
>>
>>
>
> In my experience and the way we built support for mutual TLS OAuth client
> auth the client_id value does not appear in the certificate anywhere. I'm
> not saying it can't happen but don't think it's particularly common.
>
> I can look at adding some examples, if there's some consensus that they'd
> be useful and this document moves forward.
>
>
>
>>
>> I´m not saying it is a bad Idea just that I would prefer if it was not a
>> MUST.
>> With very limited addition of code it is just as easy to get the
>> certificate attribute for client id as it is to get it from the HTTP
>> request data (at least in java). I also think that with the requirement to
>> match the incoming certificate in some way one has to read out the
>> certificate that was used to establish the connection to do some kind of
>> matching.
>>
>>
> Getting data out of the certificate isn't a concern. I just believe that
> the constancy of having the client id parameter is worth the potential
> small amount duplicate data in some cases. It's just a -00 draft though and
> if the WG wants to proceed with this document, we seek further input and
> work towards some consensus.
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

Phil, what is your +1 referring to?

//Samuel

On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) 
wrote:

> +1
>
> Phil
>
> On Nov 4, 2016, at 6:11 PM, John Bradley  wrote:
>
> I can easily see Research and education publishing self signed certs in
> meta-data that is then used for client authentication and other things.
> I don’t want to limit this to only CA issued certs where the client_id is
> in the DN.Client_id tend not to be domain names currently.
> Looking up a raw key  provided via JWK in registration based on client_id
> will be one way that people will use this.   Passing the cert is seen as
> just a way of passing the key to many people.
>
> I also understand the desire in ACE to save bytes.
>
> If you are using self signed certs then including the client_id in the
> cert vs as a parameter is a bit of a no op re size.
>
> Perhaps if there is a common pattern we could document a IoT profile where
> ca issued cert is used and what it would look like.
>
> I have concerns that this may open a can of worms around what the CN would
> be and the interpretations of use extensions if this is flagged as
> something other than a host cert.What do devices do now when they are
> issued certs.  Is there a common standard or is it by manufacturer.
>
> My main concern would be to not hold up what should be a simple spec for
> the server to server case, but am willing to accommodate IoT if possible.
>
> Regards
> John B.
>
> On Oct 28, 2016, at 5:31 PM, Brian Campbell 
> wrote:
>
> Not wanting to add more meta parameters was a motivation. Also not being
> sure of how to enumerate the possible approaches. My thinking was also that
> there are a lot of factors involved and that it'd probably be better left
> to service documentation to describe things like what authorities are
> trusted and what the client to cert binding is. Like I said, we can look at
> adding more metadata, if there's some consensus to do so. But I worry that
> it'll just be bloat that doesn't really add value.
>
> I also think that, in many situations, it's unlikely that a cert will
> contain a client id anywhere as subject information. A client id is scoped
> to a particular authorization server and it's hard to imagine a CA issuing
> a cert with an identifier that's only meaningful in the context of some
> other entity like that. Maybe in a more closed system where the AS and an
> organizational CA are both in the same management/administrative domain but
> not in the more general case.
>
>
>
> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> I see. Do you reckon the AS could simply probe the likely cert places
>> for containing the client_id? My reasoning is that there aren't that
>> many places where you could stick the client_id (let me know if I'm
>> wrong). If the AS is in doubt it will respond with invalid_client. I'm
>> starting to think this can work quite well. No extra meta param will be
>> needed (of which we have enough already).
>>
>> On 22/10/16 01:51, Brian Campbell wrote:
>> > I did consider something like that but stopped short of putting it in
>> the
>> > -00 document. I'm not convinced that some metadata around it would
>> really
>> > contribute to interop one way or the other. I also wanted to get the
>> basic
>> > concept written down before going too far into the weeds. But I'd be
>> open
>> > to adding something along those lines in future revisions, if there's
>> some
>> > consensus that it'd be useful.
>> >
>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <
>> vladi...@connect2id.com
>> >> wrote:
>> >> Superb, I welcome that!
>> >>
>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
>> >> client-auth-00#section-5.2 :
>> >>
>> >> My concern is that the choice of how to bind the client identity is
>> left
>> >> to implementers, and that may eventually become an interop problem.
>> >> Have you considered some kind of an open ended enumeration of the
>> possible
>> >> binding methods, and giving them some identifiers or names, so that AS
>> /
>> >> OPs can advertise them in their metadata, and clients register
>> accordingly?
>> >>
>> >> For example:
>> >>
>> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
>> >> "subject_public_key_info_match" ]
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Vladimir
>> >>
>> >> On 10/10/16 23:59, John Bradley wrote:
>> >>
>> >> At the request of the OpenID Foundation Financial Services API Working
>> group, Brian Campbell and I have documented
>> >> mutual TLS client authentication.   This is something that lots of
>> people do in practice though we have never had a spec for it.
>> >>
>> >> The Banks want to use it for some server to server API use cases being
>> driven by new open banking regulation.
>> >>
>> >> The largest thing in the draft is the IANA registration of
>> “tls_client_auth” Token Endpoint authentication 

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

I can see your point, maybe the client_id will not be in the certificate.
If I had an AS I would select to trust one or several CAs and then create
certificate mappings between certificate serial number (or some other
unique attribute in the certificate) and client_id. If I were to bind a
specific certificate to a client_id I lose the flexibility of the PKI
(maybe what you want).

I think multiple certificates might not be a uncommon situation especially
if you call ASs from different organizations because they will trust
different CAs.

//Samuel


On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <jric...@mit.edu> wrote:

> Jim,
>
> In those circumstances, are the clients generally calling multiple
> different services? Or just one? For those that call multiple services, are
> they using multiple (different) client certificates?
>
> I’m not saying the client would issue its own cert in all cases — much
> more common is what I’ve seen, with clients being assigned a certificate
> from a trusted CA, and then services that the client talks to being told to
> trust that CA and also assign the CN/DN of the cert a set of privileges.
> What I *haven’t* seen is a client being issued multiple certificates to
> talk to multiple systems. That latter case is common enough in the OAuth
> world that I wouldn’t want us to paint ourselves in a corner.
>
>  — Justin
>
> On Nov 3, 2016, at 10:31 AM, Jim Manico <j...@manicode.com> wrote:
>
> Thanks Justin. I use several security intel services and they all have
> different cert delivery mechanisms for mutual TLS. It's •rare• for services
> to let clients choose certs, they are usually assigned to users by each
> service from my experience.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>
> On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu> wrote:
>
> Yes, I elided the certificate issuance process. The point remains the
> same: you're not going to be submitting a CSR to the same party you're
> getting your client_id from, usually. If the draft assumes that, then it's
> incredibly limiting.
>
>
> Do people really use separate TLS client certs for separate connections in
> the wild? I've personally never seen that. What I've seen is that a piece
> of software gets its certificate that it uses to make whatever connections
> it needs to make.
>
>
>  -- Justin
>
> On 11/3/2016 8:48 AM, Jim Manico wrote:
>
> Just to be clear, the relationship should more like...
>
> AS issues public key to clients, or client sends public key to AS. The
> authorities job is NOT to give the client the public key, but to sign the
> public key for authenticity. It's bad practice to accept the full cert (pub
> key+signature) from an authority. If an authority is creating your public
> key, they are also creating your private key bad.
>
> > The client will use the same cert across multiple connections, possibly
> multiple AS's, but the same isn't true of the client_id.
>
> This seems like a bad idea. I suggest a separate key/signature for each
> service.
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>
> On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu> wrote:
>
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by the authorization server for the client
> to use at that single AS. The certificate is issued by the CA for the
> client to use on any connection. The AS and CA are not likely to be the
> same system in most deployments. The client will use the same cert across
> multiple connections, possibly multiple AS's, but the same isn't true of
> the client_id.
>
> Additionally, I think we want to allow for a binding of a self-signed
> certificate using dynamic registration, much the way that we already allow
> binding of a client-generated JWK today.
>
> I do think that more examples and guidance are warranted, though, to help
> AS developers.
>
>  -- Justin
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>>
>> I agree it is written so that the connection to the certificate is
>> implicitly required but I think it would be better if it was explicit
>> written since the lack of a connection would result in a potential security
>> hole.
>>
>
> That's fair. I agree it can be made more explicit and that it be good to
> do so.
>
>
>
>> When it comes to the client_id I think subject common name or maybe
>> subject serial numbers will be the common location, and I think an example
>> would be valuable.
&g

Re: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05

[Samuel Erdtman]

see inline

Hannes could you have a look at the comment on Security Considerations.

On Tue, Nov 1, 2016 at 7:01 PM, William Denniss <wdenn...@google.com> wrote:

> Hi Samuel,
>
> Thanks for your review! I've replied inline:
>
> On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
>> Hi,
>>
>> Thanks for the great work of putting this together. I have a few comments
>> on the current draft. See below
>>
>> Best Regards
>> Samuel Erdtman
>>
>>
>>
>> 5.  Using Inter-app URI Communication for OAuth
>> The end of this section is a bit confusing with first a MUST statement
>> and then a RECOMMENDED statement
>> “Native apps MUST use an external user-agent to perform OAuth”
>> and
>> “This best practice focuses on the browser as the RECOMMENDED external
>>user-agent for native apps.”
>>
>>
> The browser is one external user-agent. Using an external agent is a MUST
> to comply with this BCP, and the browser is the RECOMMENDED user agent.
>

My comment is not that something is formally wrong, just that I had to read
it twice before I got it. I´m fine with keeping as is, just wanted to
hilight the potential confusion.


>
>
>>
>> 7.1.1.  Custom URI Scheme Namespace Considerations
>> “For example, an app that controls the domain name "app.example.com"
>>can use "com.example.app:/" as their custom scheme.”
>> drop the slash in the custom schema.
>>
>
> Done.
>
>
>> 7.2.  App-claimed HTTPS URI Redirection
>> “When the browser encounters a claimed URL, instead of the
>>page being loaded in the browser, the native app is launched instead
>>with the URL supplied as a launch parameter.”
>> drop one “instead” changing it to:
>> “When the browser encounters a claimed URL, instead of the
>>page being loaded in the browser, the native app is launched
>>with the URL supplied as a launch parameter.”
>>
>>
> Good catch, thanks.
>
> 7.2.  App-claimed HTTPS URI Redirection
>> If this is the recommended way to do it when possible maybe it should be
>> first?
>>
>
> It's ideal in a security sense, but less broadly supported currently than
> custom URI schemes. The order is roughly based on popularity.
>

makes sense


>
> 8.1.  Embedded User-Agents
>> “Embedded user-agents are an alternative method for authorization
>>native apps.”
>> change to
>> “Embedded user-agents are an alternative method to authorize
>>native apps.”
>> or
>> “Embedded user-agents are an alternative method for authorization
>>of native apps.”
>>
>
> Fixed in 06.
>
>
>
>> 8.  Security Considerations
>> I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it
>> felt a bit odd to me to have that under Security Considerations. Not sure
>> if there are guidelines around that, but to me it would make sense to keep
>> the normative parts out of Security Considerations. And it says
>> “Considerations”, to me that sounds mor like things to think about then
>> this is how it works.
>>
>
> I actually thought it was common, but I might be wrong. I'll wait and see
> if others weigh in on this too.
>

Sounds like a plan.


>
> 8.2.  Protecting the Authorization Code
>>
>> “A limitation of using custom URI schemes for redirect URIs is that
>>multiple apps can typically register the same scheme, which makes it
>>indeterminate as to which app will receive the Authorization Code.
>>PKCE [RFC7636] details how this limitation can be used to execute a
>>code interception attack (see Figure 1).  Loopback IP based redirect
>>URIs may be susceptible to interception by other apps listening on
>>the same loopback interface.”
>>
>> I think it would be preferable to separate custom URI and Loopback IP
>> based redirect.
>>
>
> Can add a paragraph break.
>

Thanks


>
> 8.2.  Protecting the Authorization Code
>> “Loopback IP based redirect
>>URIs may be susceptible to interception by other apps listening on
>>the same loopback interface.”
>> Are you referring to an application listening to loopback traffic or an
>> application killing the original application and start listening on the
>> same port. The second alternative would be relatively intrusive and notable.
>>
>
> The former. The assumption is that other desktop apps may be able to
> observe all local HTTP traffic on the loopback interface.
>

Ok


>
> Appendix A.  Server Support Checklist
>> 1.  Support custom U

[OAUTH-WG] Review of draft-ietf-oauth-native-apps-05

[Samuel Erdtman]

Hi,

Thanks for the great work of putting this together. I have a few comments
on the current draft. See below

Best Regards
Samuel Erdtman



5.  Using Inter-app URI Communication for OAuth
The end of this section is a bit confusing with first a MUST statement and
then a RECOMMENDED statement
“Native apps MUST use an external user-agent to perform OAuth”
and
“This best practice focuses on the browser as the RECOMMENDED external
   user-agent for native apps.”


7.1.1.  Custom URI Scheme Namespace Considerations
“For example, an app that controls the domain name "app.example.com"
   can use "com.example.app:/" as their custom scheme.”
drop the slash in the custom schema.


7.2.  App-claimed HTTPS URI Redirection
“When the browser encounters a claimed URL, instead of the
   page being loaded in the browser, the native app is launched instead
   with the URL supplied as a launch parameter.”
drop one “instead” changing it to:
“When the browser encounters a claimed URL, instead of the
   page being loaded in the browser, the native app is launched
   with the URL supplied as a launch parameter.”


7.2.  App-claimed HTTPS URI Redirection
If this is the recommended way to do it when possible maybe it should be
first?


8.1.  Embedded User-Agents
“Embedded user-agents are an alternative method for authorization
   native apps.”
change to
“Embedded user-agents are an alternative method to authorize
   native apps.”
or
“Embedded user-agents are an alternative method for authorization
   of native apps.”


8.  Security Considerations
I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it
felt a bit odd to me to have that under Security Considerations. Not sure
if there are guidelines around that, but to me it would make sense to keep
the normative parts out of Security Considerations. And it says
“Considerations”, to me that sounds mor like things to think about then
this is how it works.


8.2.  Protecting the Authorization Code

“A limitation of using custom URI schemes for redirect URIs is that
   multiple apps can typically register the same scheme, which makes it
   indeterminate as to which app will receive the Authorization Code.
   PKCE [RFC7636] details how this limitation can be used to execute a
   code interception attack (see Figure 1).  Loopback IP based redirect
   URIs may be susceptible to interception by other apps listening on
   the same loopback interface.”

I think it would be preferable to separate custom URI and Loopback IP based
redirect.


8.2.  Protecting the Authorization Code
“Loopback IP based redirect
   URIs may be susceptible to interception by other apps listening on
   the same loopback interface.”
Are you referring to an application listening to loopback traffic or an
application killing the original application and start listening on the
same port. The second alternative would be relatively intrusive and notable.


Appendix A.  Server Support Checklist
1.  Support custom URI-scheme redirect URIs.
I could not see that this was required in section Section 7.1.


Appendix A.  Server Support Checklist
5.  Support PKCE.
in Section 8.2 it says MUST
“Authorization servers MUST support PKCE [RFC7636]
   for public native app clients.”
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

Thanks for the reply Brian,

See inline

On Fri, Oct 28, 2016 at 10:56 PM, Brian Campbell <bcampb...@pingidentity.com
> wrote:

>
> On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman <sam...@erdtman.se>
> wrote:
>
>> I think it is awesome that this document has been written since this is
>> one of the solutions that exists in the wild.
>>
>>
> Thanks. To some extent I was working to codify those existing solutions,
> which is one of the reasons why the specific binding between client and
> certificate is left open ended.
>
>
>
>> However I think that the connection to client (client_id) and certificate
>> could be more clearly specified, at the moment it is exemplified under
>> security considerations. I think there should be text saying that there
>> MUST be a binding and provide the default solution e.g. client_id as
>> subject common name.
>>
>
> I sort of thought the need for connection between client and certificate
> was implicit in the text that is in section 2. But I can work to make the
> language more explicit. As I mentioned in my recent reply to Vladimir, I
> expect client_id as subject common name to be more the exception rather
> than the common case so don't feel it'd be appropriate as a default.
>

I agree it is written so that the connection to the certificate is
implicitly required but I think it would be better if it was explicit
written since the lack of a connection would result in a potential security
hole.

When it comes to the client_id I think subject common name or maybe subject
serial numbers will be the common location, and I think an example would be
valuable.


>
>
>>
>> Further I would prefer if it was not a MUST to include the client_id in
>> the HTTP request since I think there MUST exist a client binding in the
>> certificate. I think there is no need to have it explicitly in the HTTP
>> request. This might not be a problem for Classic OAuth but when adopted for
>> ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
>> we would like to lessen the duplicated information as much as possible.
>>
>
> There needs to be a binding between the client and certificate but that
> doesn't mean the client id will be in the certificate. Having the client id
> explicitly available in the HTTP request allows the AS to easily identify
> the client independently and consistently from the content of the
> certificate or key and allows the AS to not have to index its client
> storage by some other value. It may lead to a small amount of duplicate
> info in some cases but I believe the consistency is worth it.
>

I´m not saying it is a bad Idea just that I would prefer if it was not a
MUST.
With very limited addition of code it is just as easy to get the
certificate attribute for client id as it is to get it from the HTTP
request data (at least in java). I also think that with the requirement to
match the incoming certificate in some way one has to read out the
certificate that was used to establish the connection to do some kind of
matching.


>
>
>
>>
>>
>>
> //Samuel
>>
>>
>> On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <
>> vladi...@connect2id.com> wrote:
>>
>>> I see. Do you reckon the AS could simply probe the likely cert places
>>> for containing the client_id? My reasoning is that there aren't that
>>> many places where you could stick the client_id (let me know if I'm
>>> wrong). If the AS is in doubt it will respond with invalid_client. I'm
>>> starting to think this can work quite well. No extra meta param will be
>>> needed (of which we have enough already).
>>>
>>> On 22/10/16 01:51, Brian Campbell wrote:
>>> > I did consider something like that but stopped short of putting it in
>>> the
>>> > -00 document. I'm not convinced that some metadata around it would
>>> really
>>> > contribute to interop one way or the other. I also wanted to get the
>>> basic
>>> > concept written down before going too far into the weeds. But I'd be
>>> open
>>> > to adding something along those lines in future revisions, if there's
>>> some
>>> > consensus that it'd be useful.
>>> >
>>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <
>>> vladi...@connect2id.com
>>> >> wrote:
>>> >> Superb, I welcome that!
>>> >>
>>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
>>> >> client-auth-00#section-5.2 :
>>> >>
>>> >> My concern is that the choice of how to bind t

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman]

I think it is awesome that this document has been written since this is one
of the solutions that exists in the wild.

However I think that the connection to client (client_id) and certificate
could be more clearly specified, at the moment it is exemplified under
security considerations. I think there should be text saying that there
MUST be a binding and provide the default solution e.g. client_id as
subject common name.

Further I would prefer if it was not a MUST to include the client_id in the
HTTP request since I think there MUST exist a client binding in the
certificate. I think there is no need to have it explicitly in the HTTP
request. This might not be a problem for Classic OAuth but when adopted for
ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
we would like to lessen the duplicated information as much as possible.

//Samuel


On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov  wrote:

> I see. Do you reckon the AS could simply probe the likely cert places
> for containing the client_id? My reasoning is that there aren't that
> many places where you could stick the client_id (let me know if I'm
> wrong). If the AS is in doubt it will respond with invalid_client. I'm
> starting to think this can work quite well. No extra meta param will be
> needed (of which we have enough already).
>
> On 22/10/16 01:51, Brian Campbell wrote:
> > I did consider something like that but stopped short of putting it in the
> > -00 document. I'm not convinced that some metadata around it would really
> > contribute to interop one way or the other. I also wanted to get the
> basic
> > concept written down before going too far into the weeds. But I'd be open
> > to adding something along those lines in future revisions, if there's
> some
> > consensus that it'd be useful.
> >
> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
> >> client-auth-00#section-5.2 :
> >>
> >> My concern is that the choice of how to bind the client identity is left
> >> to implementers, and that may eventually become an interop problem.
> >> Have you considered some kind of an open ended enumeration of the
> possible
> >> binding methods, and giving them some identifiers or names, so that AS /
> >> OPs can advertise them in their metadata, and clients register
> accordingly?
> >>
> >> For example:
> >>
> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
> >> "subject_public_key_info_match" ]
> >>
> >>
> >> Cheers,
> >>
> >> Vladimir
> >>
> >> On 10/10/16 23:59, John Bradley wrote:
> >>
> >> At the request of the OpenID Foundation Financial Services API Working
> group, Brian Campbell and I have documented
> >> mutual TLS client authentication.   This is something that lots of
> people do in practice though we have never had a spec for it.
> >>
> >> The Banks want to use it for some server to server API use cases being
> driven by new open banking regulation.
> >>
> >> The largest thing in the draft is the IANA registration of
> “tls_client_auth” Token Endpoint authentication method for use in
> Registration and discovery.
> >>
> >> The trust model is intentionally left open so that you could use a
> “common name” and a restricted list of CA or a direct lookup of the subject
> public key against a reregistered value,  or something in between.
> >>
> >> I hope that this is non controversial and the WG can adopt it quickly.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >>
> >>
> >>
> >> Begin forwarded message:
> >>
> >> From: internet-dra...@ietf.org
> >> Subject: New Version Notification for draft-campbell-oauth-tls-
> client-auth-00.txt
> >> Date: October 10, 2016 at 5:44:39 PM GMT-3
> >> To: "Brian Campbell"  <
> brian.d.campb...@gmail.com>, "John Bradley"  <
> ve7...@ve7jtb.com>
> >>
> >>
> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
> >> has been successfully submitted by John Bradley and posted to the
> >> IETF repository.
> >>
> >> Name:draft-campbell-oauth-tls-client-auth
> >> Revision:00
> >> Title:   Mutual X.509 Transport Layer Security (TLS)
> Authentication for OAuth Clients
> >> Document date:   2016-10-10
> >> Group:   Individual Submission
> >> Pages:   5
> >> URL:https://www.ietf.org/internet-
> drafts/draft-campbell-oauth-tls-client-auth-00.txt
> >> Status: https://datatracker.ietf.org/
> doc/draft-campbell-oauth-tls-client-auth/
> >> Htmlized:   https://tools.ietf.org/html/draft-campbell-oauth-tls-
> client-auth-00
> >>
> >>
> >> Abstract:
> >>   This document describes X.509 certificates as OAuth client
> >>   credentials using Transport Layer Security (TLS) mutual
> >>   authentication as a mechanism for client authentication to the
> >>   

Re: [OAUTH-WG] Future of PoP Work

[Samuel Erdtman]

+1 on doing PoP work in this working group, including HTTP signing/MACing,
I don´t think the old HTTP signature document was that far from useful.

With the ACE work I like when it is possible to just map work done in the
OAuth and other working groups to the more optimized protocols. Some would
maybe say that it is sub-optimal that the protocol was not initially
designed for the constrained environment but I think the benefit of concept
validation from web is a bigger plus.

//Samuel

On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer  wrote:

> I believe that the PoP work should stay in the working group, and that
> without a usable presentation mechanism such as an HTTP message signature
> the whole work is pointless. I agree with Mike that we should learn from
> our own mistakes — and that is precisely the direction that the current
> HTTP signing draft took. As a result, the base level of functionality is
> signing the token itself (with a timestamp/nonce) using the key. All of the
> fiddly HTTP bits that trip people up? Not only are they optional, but it’s
> explicitly declared what’s covered. Why? Because we’re learning from past
> mistakes.
>
> I think that token binding is relying on a lot of “ifs” that aren’t real
> yet, and if those “ifs” become reality then it will be to the benefit of
> large internet companies over everyone else. Additionally, token binding in
> OAuth is far from the simple solution that it’s being sold as. The very
> nature of an access token goes against the original purpose of tying an
> artifact to a single presentation channel. OAuth clients in the real world
> need to be able to deal with multiple resource servers and dynamically
> deployed APIs, and the token binding protocol fundamentally assumes a world
> where two machines are talking directly to each other.
>
> All that said, this working group has consistently shown resistance to
> solving this problem for many years, so the results of this query don’t at
> all surprise me.
>
>  — Justin
>
> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
> >
> > Hi all,
> >
> > two questions surfaced at the last IETF meeting, namely
> >
> > 1) Do we want to proceed with the symmetric implementation of PoP or,
> > alternatively, do we want to move it over to the ACE working group?
> >
> > 2) Do we want to continue the work on HTTP signing?
> >
> > We would appreciate your input on these two questions.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > 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] poll url in draft-ietf-oauth-device-flow-01

[Samuel Erdtman]

Hi,

I just manage to take the time to read this document and in general I like
it a lot I think it fills a gap and with mapping to CBOR, and CoAP it will
work well for more constrained deceive too.

There are several details that would be great to address such as IANA
section more thorough descriptions of device_code and user_code and It
would also be good with more examples e.g. a poll example.

The above things one can figure out relatively easy but how and where are
poll requests sent. Is it new post requests to the token endpoint with the
device_code included; or is it get requests to the token endpoint with the
device_code; or is it a completely different endpoint?
A solution that I would like is to have a poll url instead of the
device_code then the client does not need to know how to construct the poll
url form the device_code.

Is there a github repo or something similar that I could send pull requests
to?

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

Re: [OAUTH-WG] [Ace] PoP, Introspection and ACE

[Samuel Erdtman]

Thanks John for your reply, have you had time to discuss a way forward with
Hannes.

I agree we should absolutely register cnf in introspection to go inline
with RFC 7800.

Since RFC 7800 is done it might be preferable to do the registration in the
ACE specification that is the specification that needs it.

//Samuel


On Sun, Apr 17, 2016 at 1:23 AM, John Bradley <ve7...@ve7jtb.com> wrote:

> It is probably best to register “cnf” to match RFC 7600 so we don’t have
> two different structures one for JWT/CWT and one for introspection.
>
> On the other hand introspected tokens are generally relatively custom in
> what claims they pass.
>
> I will discuss it with Hannes.
>
> John B.
>
> On Apr 16, 2016, at 6:42 PM, Samuel Erdtman <sam...@erdtman.se> wrote:
>
> Hi,
>
> I'm working on the IANA section in
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.
>
> In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz we want to have
> the option to get the PoP parameters (alg, key and aud) via introspection
> e.g. if using a reference token.
>
> At the moment I wrote the registration text of the parameters in the ACE
> specification but I think it would be preferable if
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution did the
> registration for introspection too.
>
> Comments?
>
> //Samuel
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] PoP, Introspection and ACE

[Samuel Erdtman]

Hi,

I'm working on the IANA section in
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.

In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz we want to have
the option to get the PoP parameters (alg, key and aud) via introspection
e.g. if using a reference token.

At the moment I wrote the registration text of the parameters in the ACE
specification but I think it would be preferable if
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution did the
registration for introspection too.

Comments?

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

Re: [OAUTH-WG] OAuth 2.1

[Samuel Erdtman]

+1 on a 2.1 version

-1 on defining scopes more precisely in 2.1

Sent from my iPhone

> On 7 apr. 2016, at 14:46, Anthony Nadalin  wrote:
> 
> I don't belive that scopes should be defined more precisely as this 
> opaqueness was a design feature, I'm not seeing the reason why scopes need to 
> be defined, as these are application specific.
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Thursday, April 7, 2016 5:32 AM
> To: George Fletcher 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
> 
> Hi all,
> 
> as I already said in the meeting: I would very much prefer to have an 
> extension/update of RFC 6819 covering all "new" threats, including:
> - mix up
> - code injection aka copy and paste
> - open redirector at AS and client
> - potential other threats in the context of "dynamic" OAuth
> 
> I also assume mitigations for (at least some of) the threats need to go into 
> an update of RFC 6749 as normative text. To give an example: if we agree on 
> using the state parameter at the token endpoint to mitigate code injection, 
> this MUST be part of the core spec (request description and security 
> consoderations). Otherwise, noone will even  consider it.
> 
> We should also use the opportunity to improve/enhance the text of the spec. 
> In the course of the last years, we have learned a lot about ambiquities of 
> the text and how different implementations utilize OAuth. 
> 
> I think time is right to define scopes more precisely. As the discussions in 
> the last days proved again (at least for me), scope is not sufficiently 
> defined to come up with interoperable implementations. Additionally, there 
> seems to be a need to represent resource server locations (to not say 
> identities :-)) in this context.
> 
> To bundle all changes in a version 2.1 would also make communication into the 
> market much easier. 
> 
> best regards,
> Torsten.
> 
>> Am 06.04.2016 um 16:05 schrieb George Fletcher :
>> 
>> I'd definitely prefer a single solution document to many little ones that 
>> have to be combined to actually build a secure solution. It's already 
>> getting complex with the additional specs that have been added.
>> 
>> Additionally, I'm not against working on OAuth 2.1.
>> 
>> Thanks,
>> George
>> 
>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>> 
>>> Existing implementations are for the large part ok and do not need these 
>>> mitigations.
>>> 
>>> Only the new use cases we have been discussing (configure on the fly and 
>>> multi-as, etc) really need mitigation.
>>> 
>>> The updated by approach seems like a good way to address the new cases.
>>> 
>>> Phil
>>> 
 On Apr 6, 2016, at 14:35, Hannes Tschofenig  
 wrote:
 
 Hi all,
 
 today we discussed the OAuth Authorization Server Mixup draft. We 
 were wondering what types of threats the document should find solutions 
 for.
 
 We discussed various document handling approaches including
 * OAuth Mix-Up and Cut-and-Paste attacks documented in separate 
 solution documents
 * combined solution document covering the OAuth Mix-Up and the 
 Cut-and-Paste attacks.
 
 Barry pointed out that these documents could update the OAuth base 
 specification.
 
 As a more radical change it was also suggested to revise RFC 6749 
 "OAuth
 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model 
 and Security Considerations".
 
 Opening up the OAuth base specification obviously raises various 
 other questions about cleaning up parts that go far beyond the AS 
 mix-up and the cut-and-paste attacks. Other specifications, such as 
 the Open Redirector, could be folded into such a new specification.
 
 Derek and I would appreciate your input on this topic before we make 
 a decision since it has significant impact on our work.
 
 Ciao
 Hannes & Derek
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
 .ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40micr
 osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2
 d7cd011db47%7c1=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>> ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40micros
>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c
>>> d011db47%7c1=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i

Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

[Samuel Erdtman]

+1 for adoption

Sent from my iPhone

> On 7 apr. 2016, at 03:34, Kepeng Li  wrote:
> 
> To: ACE WG
> Cc: OAuth and COSE WG
> 
> Hello all,
> 
> This note begins a Call For Adoption for 
> draft-wahlstroem-ace-cbor-web-token-00 [1]
> to be adopted as an ACE working group item, and added in the charter.
> The call ends on April 22, 2016.
> 
> Keep in mind that adoption of a document does not mean the document
> as-is is ready for publication. It is merely acceptance of the
> document as a starting point for what will be the final product
> of the ACE working group. The working group is free to make changes to
> the document according to the normal consensus process.
> 
> Please reply on this thread with expressions of support or opposition,
> preferably with comments, regarding accepting this as a work item.
> 
> Note that this email was also copied to OAuth and COSE WG, in order to 
> get input from wider audience.
> 
> Thanks,
> 
> Kind Regards
> Kepeng (ACE co-chair)
> 
> [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/
> 
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Samuel Erdtman]

Thanks Mike!

Then lets take it to the next level :)

//Samuel

On Thu, Mar 10, 2016 at 12:33 PM, Mike Jones <michael.jo...@microsoft.com>
wrote:

> Thanks for your comments, Samuel.  Yes, you’re right that jwks_uri should
> be OPTIONAL, since not all use cases need keys.  Likewise,
> registration_endpoint should be OPTIONAL, rather than RECOMMENDED.
>
>
>
> The grant_type values are defined in OAuth Dynamic Client Registration
> [RFC 7591] and are identifiers for the grant type concept defined in RFC
> 6749.  They identify the grant types that can be used at the Token
> Endpoint.  The response_type concept is defined in RFC 6749, and identifies
> a response syntax from the authorization endpoint.  We can say more to
> differentiate these in the next draft.
>
>
>
> BTW, lest it be in doubt, I support this draft moving forward, with the
> name changed to “OAuth 2.0 Authorization Server Discovery” or “OAuth 2.0
> Authorization Server Discovery Metadata” – as discussed in the thread
> “OAuth 2.0 Discovery Location”.  I’m also open to introducing the 
> “/.well-known/oauth-authorization-server”
> identifier, as discussed in that thread.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig <hannes.tschofe...@gmx.net>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Hi,
>
>
>
> I sent a few comments two weeks ago that has not been explicitly commented
> on. (I might have sent them in the wrong way, if so sorry about that)
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
>
>
>
> Most of the comments are minor but I would like to se
>
> jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
>
> and at least get a comment of the difference
> between response_types_supported and grant_types_supported
>
>
>
> Best regards
>
> //Samuel
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Samuel Erdtman]

Hi,

I sent a few comments two weeks ago that has not been explicitly commented
on. (I might have sent them in the wrong way, if so sorry about that)

https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w

Most of the comments are minor but I would like to se
jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
and at least get a comment of the difference between response_types_supported
and grant_types_supported

Best regards
//Samuel




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] HTTP signing spec and nonce

[Samuel Erdtman]

To me it seems reasonable that a client may send multiple signed messages
in one second.

So I´m +1 for a nonce. A more fine grained timestamp is nice but I think we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecond.

//Samuel

On Sun, Feb 28, 2016 at 10:34 PM, Justin Richer  wrote:

> I understand how they work, I’ve built exactly that cache before. But I
> askWouldn’t a unique timestamp have the same effect? Currently it’s integer
> seconds but slicing that down further (floating point seconds?) if people
> desired would allow for multiple signed messages in the same second from
> the same client using the otherwise same parameters.
>
> “Other protocols do it” is not a compelling reason on its own, especially
> when the example of “other protocols” includes WS-* ;)
>
> Seriously though, an optional nonce is easy to add to the draft if there’s
> enough WG support, I’m just hesitant to add more complexity than needed to
> this.
>
>  — Justin
>
> On Feb 26, 2016, at 11:06 PM, Dominick Baier 
> wrote:
>
> The nonce would allow to build a replay cache, the timestamp to trim that
> cache and reject messages that are too old.
>
> Similar protocols have a nonce for the above reasons (ws-sec msg security,
> hawk)...
>
> —
> cheers
> Dominick Baier
>
> On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu) wrote:
>
> I’d be glad to add in a nonce if there’s a compelling reason for it, such
> as closing a security attack vector.
>
> What’s the proposed purpose of the nonce? Is it just to add randomness to
> the signing base? Or is it to prevent replay at the RS? If the former, the
> timestamp should add enough of that and it can be verified to be within a
> reasonable window by the RS by comparing it with the time the request was
> made. If the latter, the RS is going to have to track previously used
> nonces for some amount of time.
>
> There was a small discussion of just signing an outgoing “Date:” header
> instead of the separate timestamp, but the timestamp seemed to be more
> robust. I forget the full reasoning though.
>
>  — Justin
>
> On Feb 26, 2016, at 9:49 AM, Brock Allen  wrote:
>
> Question about the HTTP signing spec – why is there no nonce (and just a
> timestamp)?
>
> TIA
>
> -Brock
>
> ___
> 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] OAuth 2.0 Discovery Location

[Samuel Erdtman]

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
wrote:

> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
> 2.0 Authorization Server Discovery”.  While the abstract already makes it
> clear that the scope of the document is AS discovery, doing so in the title
> seems like it could help clarify things, given that a lot of the discussion
> seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but
> unlike authorization server discovery, where there’s lots of existing
> practice, including using the existing data format for describing OAuth
> implementations that aren’t being used with OpenID Connect, there’s no
> existing practice to standardize for resource discovery.  The time to
> create a standard for that seems to be after existing practice has
> emerged.  It **might** or might not use new metadata values in the AS
> discovery document, but that’s still to be determined.  The one reason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
> document is about the AS.  We don’t yet have a specification or existing
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> ·   “OAuth 2.0 Discovery”
>
> ·   “OAuth 2.0 Authorization Server Discovery”
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vladimir
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> In OIDC the discovery doc is of great utility to developers and
> integrators. Developers also tend to find it a more accurate and complete
> description of how to set up a client for a particular deployment, compared
> to traditional online docs, which may be not be up to date, or even
> missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration
>
> https://www.paypalobjects.com/.well-known/openid-configuration
>
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>
>
> With this discovery document in place setup of identity federation can
> then be easily scripted. For example:
>
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>
>
> Now, does that dictate any particular app architecture? My reading of the
> spec is that it doesn't, and it shouldn't either. By staying neutral on the
> topics of RS discovery and registering RPs with RSs. And how one arrives at
> the ".well-known/...". I'm not even sure that resource discovery should be
> a topic of this WG. Perhaps to this end, and to prevent confusion that the
> spec is trying to do something more, a more specific title would suit it
> better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
>
>
> So how can an app dictate it then unless we all go to a common architecture?
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 16:04, Mike Jones  
>  wrote:
>
>
>
> Azure defines ways for resource servers to be registered for use with a 
> client and for clients to dynamically request an access token for use at a 
> particular resource server.  You can call that custom architecture if you 
> want.  It’s well-defined but it’s not currently in the standards realm.  I 
> know that Google has syntax for doing the same, as I’m sure do a lot of other 
> cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working 
> group talked about possibly producing a standard version of syntax for making 
> these kinds of requests during our discussions in Prague (during the Token 
> Exchange discussion) but nobody has run with this yet.
>
>  In this sense, yes, Azure is an application of the kind we’re talking about. 
>  Azure already does define specific new OAuth 2.0 discovery metadata values 
> that are used in production.  A registry just doesn’t yet exist in which it 
> can register those that are of general applicability.
>
>  -- Mike
>
>  From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com ]
>
> Sent: Wednesday, February 24, 2016 3:52 PM
>
> To: Mike Jones
>
> Cc:  

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Samuel Erdtman]

Hi,

I agree that the user of “/.well-known/openid-configuration” is confusing and
that it would be preferable with something else, but it is written as an
example not necessarily a default.

However to use “/.well-known/oauth-authorization-server” might be
problematic if as written different applications needs different content in
the discovery endpoint. (3.  Obtaining Authorization Server Discovery
Metadata)

//Samuel

On Fri, Feb 19, 2016 at 10:59 PM, Justin Richer  wrote:

> The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of “/.well-known/openid-configuration” in the discovery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the
> default discovery location, and state that the document MAY also be
> reachable from “/.well-known/openid-configuration” if the server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
>
>  — Justin
> ___
> 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] OAuth 2.0 Discovery Location

[Samuel Erdtman]

Hi,

Here coms some review comments, In general I think this is a good document.

//Samuel


2.  Authorization Server Metadata

token_endpoint, I would prefer if the requiredness of this parameter was
put in the beginning instead of the end as with the other parameters.

jwks_uri, I would like to change to recommended since this is not a
parameter required by the base OAuth 2.0 framework similar to
registration_endpoint

jwks_uri, It would be nice with a referens to the definition of jwks_uri.

jwks_uri, “When both signing and encryption keys are made available, a
"use" (public key use) parameter value is REQUIRED for all keys in the
referenced JWK Set to indicate each key's intended usage”
The text would be simpler if it just said that “use” always was required.
It would also be one less thing to argue about when it comes to
interoperability if it was always required.

response_types_supported, an example would be appreciated and maybe a
referees to the response type definition

response_types_supported, What is the difference between
response_types_supported and grant_types_supported, with a quick look they
seem very similar. Could it be enough with one of them?


introspection_endpoint_auth_signing_alg_values_supported,
revocation_endpoint_auth_signing_alg_values_supported and
token_endpoint_auth_signing_alg_values_supported, it would be good with a
reference to the definition of "private_key_jwt" and "client_secret_jwt"

token_endpoint_auth_methods_supported, why not refer to IANA registry for
"OAuth Token Endpoint Authentication Methods" under [IANA.OAuth.Parameters]
in the same way as with
introspection_endpoint_auth_signing_alg_values_supported and
revocation_endpoint_auth_signing_alg_values_supported



3.  Obtaining Authorization Server Discovery Metadata
As also mentioned by Justin I think it is a bit confusing with the example
opened-configuration as .well-known/ postfix could it be made clearer that
it is ab example maybe by making "/.well-known/example-configuration" the
primary example.



5.  Compatibility Notes
”http://openid.net/specs/connect/1.0/issuer; is only used in this section,
maybe it should be removed?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Samuel Erdtman]

Hi,

I think it is a reasonable simplification to mandate that PoP key and
(D)TLS Mode matches i.e. if the PoP keys is symmetric the (D)TLS mode would
be PSK, if the PoP key is asymmetric (D)TLS mode would be Raw Public key.

But I think there is some compelling properties of having a symmetric PoP
key and a Raw Public Key (D)TLS. In this case the Public key of the RS can
be distributed to the client in the client information (the attributes
accompanying the token) from AS and the PoP key as defined by PoP key
distribution draft. With this setup the client can authenticate the server
at connection time and then it can send its PoP token to authorization
information endpoint/resource at the RS (defined in
draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization
header) to authorize the client.

Regards
//Samuel





On Thu, Feb 4, 2016 at 10:54 AM, Ludwig Seitz  wrote:

> Hello list(s),
>
> in the process of updating our draft [1] (mainly in reaction to the
> reviewer's comments) I've come up with a question I'd like to put to the
> list (crossposting to OAuth as well, they might have considered that
> already):
>
> Assuming we are using (D)TLS to secure the connection between C and RS,
> assuming further that we are using proof-of-possession tokens [2], i.e.
> tokens linked to a key, of which the client needs to prove possession in
> order for the RS to accept the token.
>
> Do we need to support cases, where the type of key used with DTLS does not
> match the type of key in the PoP-token?
>
> Example:
>
> The client uses its raw public key as proof of possession, but the DTLS
> connection C - RS is secured with a pre-shared symmetric key.
>
> Is that a realistic use case?
>
> It would simplify the DTLS cases a lot, if I could just require the token
> and the DTLS session to use the same type of key. For starters we could use
> DTLS handshake to perform the proof-of-possession.
>
> Would there be any security issues with using the PoP key in the DTLS
> handshake?
>
> I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279
> and raw public PoP keys as client-authentication key as in
> RFC7250.
>
>
> Regards,
>
> Ludwig
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
> [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02
>
>
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
>
> Phone +46(0)70 349 9251
> http://www.sics.se
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth