Olaf's compromise text looks OK to me. If no one objects I'll submit this later
today.
/Ludwig
Sent from my smartphone
Olaf Bergmann wrote
>Hi Carsten, Ludwig,
>
>I think removing the discussed is not an option as the whole discussion
>was about "something needs to be said" but
Hi Carsten, Ludwig,
I think removing the discussed is not an option as the whole discussion
was about "something needs to be said" but not being clear about what
this is.
On 2021-07-10, Carsten Bormann wrote:
> Maybe we can combine these two into one sentence that covers a common
>
On 2021-07-10, at 12:07, Ludwig Seitz wrote:
>
> I can remove the text entirely, since we don't seem to agree on the details.
> Would that be acceptable?
I can’t answer that question, but it seems to me that we both have a
requirement in mind. The text that resulted from processing my
How do we get this done before Monday’s I-D deadline?
On 2021-07-06, at 08:22, Ludwig Seitz wrote:
>
> Hello Francesca, Carsten,
>
> Sorry but I do not like what you did in the first sentence. Combining
> profiles does not necessarily equate to creating a new one, and I still don't
> see why
Hi Francesca,
Thanks for picking this up and turning it serious.
There is a BCP14 alert here, though:
> A profile MAY want to prepare for being combined with others by clearly
> specifying
> its security requirements.
The BCP14 keyword MAY would be appropriate to announce some behavior
; Cigdem Sengul ; Göran Selander
; ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Hi Carsten,
I like your proposals! I changed a "define" to "specify" to remove
Hi Carsten,
I like your proposals! I changed a "define" to "specify" to remove some
repetition, so finally the text change would be the following:
OLD:
There may be use cases were different profiles of this framework are
combined. For example, an MQTT-TLS profile is used between the
On 2021-07-05, at 16:15, Carsten Bormann wrote:
>
> The last sentence is kind of obvious (I hope that the same applies to
> non-combined profiles), but Section 6.7 is short, so a little superfluity
> does not hurt.
In offline communication, I have been reminded that adding this sentence would
Hi Francesca:
On 2021-07-05, at 15:32, Francesca Palombini
wrote:
>
> NEW:
> There may be use cases were different transport and security protocols
Amazingly, this still says “were” where it needs to say “where”, as if the
“were” were invisible :-)
> are allowed for the different
eitz ;
art-...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; The IESG
; Seitz Ludwig ; ace@ietf.org;
Francesca Palombini
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Hi all,
There is an unresolved issue
On 29. Jun 2021, at 20:11, Daniel Migault wrote:
>
> Hi,
>
> So here is the current text:
> """
> CBOR is a binary encoding designed for small code and message size.
> Self-contained tokens and protocol message payloads are encoded in CBOR when
> CoAP is used.
> """
>
> I think Carsten is
> Cc: Francesca Palombini ; Seitz
> Ludwig ; The IESG ;
> art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org;
> ace@ietf.org
> > Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
> draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
09:15
> To: Ludwig Seitz
> Cc: Francesca Palombini ; Seitz Ludwig
> ; The IESG ; art-...@ietf.org;
> ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
> Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
> draft-ietf-ace-oauth-authz-38: (with DISCUSS
Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
> In 2021-06-09, at 08:42, Ludwig Seitz wrote:
>
> " ... size. Self-contained tokens and protocol message payloads are encoded
> in CBOR when CoAP is used.”
This is not what the old NEW text says.
(The new
> In 2021-06-09, at 08:42, Ludwig Seitz wrote:
>
> " ... size. Self-contained tokens and protocol message payloads are encoded
> in CBOR when CoAP is used.”
This is not what the old NEW text says.
(The new NEW text attaches the “when” to both arms.)
The whole idea of attaching the
Hello Francesca,
Comments inline. Update will be posted shortly.
/Ludwig
-Original Message-
From: Francesca Palombini
Sent: den 10 maj 2021 20:42
To: Seitz Ludwig ; The IESG
Cc: art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org;
ace@ietf.org
Subject: Re:
Hi Ludwig, authors,
Thank you for all the work on the document.
I have checked all my comments (including those that you have addressed in v-39
and not reported below), and I am good with almost all of them.
Considering the clarifications added as a response to my comments regarding
CoAP
Hello Francesca,
Thank you for your review, sorry for the long response time.
Version -39 addresses some of your comments
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39
I have replies on the remaining comment as follows below (prefixed with 'LS:')
Regards,
Ludwig
1.
On 2021-03-25, at 16:57, Francesca Palombini
wrote:
>
> 13. -
>
> valid access token. The AS Request Creation Hints message is a CBOR
> map, with an OPTIONAL element "AS" specifying an absolute URI (see
>
> FP: another case where CBOR seem mandatory.. Is this the case, even if HTTP
Sent: Thursday, March 25, 2021 3:59 PM
To: Cigdem Sengul ; Francesca Palombini
; Hannes Tschofenig
Cc: Seitz Ludwig ; The IESG ;
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org;
sec-...@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Dis
To: Cigdem Sengul ; Francesca Palombini
; Hannes Tschofenig
Cc: Seitz Ludwig ; The IESG ;
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org;
sec-...@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMME
Hi Cigdem,
I just quickly scanned the MQTT profile, and noticed that for example the C-AS
interaction defined in the MQTT-TLS profile (using a new media type
"application/ace+json") do not map with what is currently defined in the ACE
framework (which maps more closely to what OAuth 2.0 does,
: Thursday, March 25, 2021 3:10 PM
To: Francesca Palombini
Cc: Seitz Ludwig ; The IESG ;
art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org;
ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS
Hello,
I would like to add my two cents to this as the MQTT-TLS profile does use
HTTP/JSON for client-AS and rs-AS communication as similar already was
supported in MQTT implementations between an MQTT broker and external
servers (e.g., via auth plug-ins).
For points like 13: Making CBOR
Ludwig,
Thank you for the quick reply, and for the useful background information.
As I said, I think this document is important and should move forward asap, and
it can do so without changing the main assumptions, with some additional
clarifications in the text about CBOR vs "other" when HTTP
Hello Francesca,
Thank you for your review. I will address your detailed comments separately,
with regards to your DISCUSS:
The option to allow both HTTP and JSON for any leg of the communication
(client-AS, rs-AS, client-rs) was the result of long discussions in the WG. If
I recall correctly
26 matches
Mail list logo
