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 som
ented.
>
> 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
t, 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 s
.
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 s
t.
> 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
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
/
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
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
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
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
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
-
From:
Date: Tue, 21 Nov 2017 at 11:09
Subject: New Version Notification for draft-erdtman-oauth-rpcc-00.txt
To: Marco Tiloca , Ludwig Seitz ,
Samuel Erdtman
A new version of I-D, draft-erdtman-oauth-rpcc-00.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF
Notification for draft-erdtman-ace-rpcc-02.txt
To: Ludwig Seitz , Samuel Erdtman
A new version of I-D, draft-erdtman-ace-rpcc-02.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.
Name: draft-erdtman-ace-rpcc
Revision: 02
Title: Raw
Ping
On Thu, Sep 7, 2017 at 10:11 PM, Samuel Erdtman 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 mig
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_cl
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 newli
ce [mailto:ace-boun...@ietf.org] *On Behalf Of *Samuel Erdtman
> *Sent:* Friday, May 12, 2017 1:03 AM
> *To:* ; ace
> *Cc:* Ludwig Seitz
> *Subject:* [Ace] New OAuth client credentials RPK and PSK
>
>
>
> Hi ACE and OAuth WGs,
>
> I and Ludwig submitted a new draft
ietf-mtls?
>
> best regards,
> Torsten.
>
> Am 12.05.2017 um 10:03 schrieb Samuel Erdtman :
>
> 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,
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
+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 Sakimu
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 wrote:
>
>> Thanks for the replies.
>>
>> If there are no formal guidelines from IETF
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 wrote:
> I've been collecting opinions about the best OAuth2 workflows for SPA
> applications
gt;> that sub-section should probably be reworded since RFC6749 already
>> establishes the public client type, which native apps are and a reference
>> would be more appropriate (which would reduce it to just clarifying an old
>> topic).
>>
>> What do you think of th
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
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 s
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
, lets see what others think.
On Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell 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 wrote:
Fri, 11 Nov 2016 at 19:13, Brian Campbell
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
eeded for that case.
>
> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote:
>
> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote:
>
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The
g/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:
>
>
> O
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 authenticat
gt;
> 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 develope
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 wrote:
> Hi Samuel,
>
> Thanks for your review! I've replied inline:
>
> On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman wrote:
>
>> H
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
Thanks for the reply Brian,
See inline
On Fri, Oct 28, 2016 at 10:56 PM, Brian Campbell wrote:
>
> On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman
> wrote:
>
>> I think it is awesome that this document has been written since this is
>> one of the solutions
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 th
+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
ma
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 descrip
ly custom in
> what claims they pass.
>
> I will discuss it with Hannes.
>
> John B.
>
> On Apr 16, 2016, at 6:42 PM, Samuel Erdtman wrote:
>
> Hi,
>
> I'm working on the IANA section in
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.
>
> I
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 wrot
+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
+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 char
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [
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 change
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 millisecon
+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 Discover
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 appli
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 c
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
49 matches
Mail list logo
