Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

On Feb 2, 2018, at 23:24, Benjamin Kaduk wrote: > > Finally, in the acknowledgments, we can ask the RFC Editor to use > the non-ASCII "Gőran" if he so desires. (Last I heard the tooling > isn't there to use non-ASCII for internet drafts yet, though.) We have the same issue in RFC 8323-to-be (Co

Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

» Depending upon the values being requested, registration requests are evaluated on a Standards Track Required, Specification Required, Expert Review, or Private Use basis [RFC8126] « This might give the impression that IANA registrations can be made on a “Private Use” basis. RFC 8126

Re: [Ace] Removal of the Client Token from ACE-OAuth draft

On Feb 5, 2018, at 08:01, Ludwig Seitz wrote: > > I agree that interest for this use case has been lukewarm at most in the WG. Well, IoT is a vast field and we cannot expect all areas of it to be represented equally well in the WG yet. > I will remove that feature from the draft in the next up

[Ace] Constrained Node/Network Cluster @ IETF101: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF101. Remember that there is still quite some potential for changes. The painful ones (not necessarily fixable) this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE vs. ANIMA, CORE vs. QUI

[Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Page 50: * Register the client at the AS. This includes making known to the AS which profiles, token_types, and key types (symmetric/ asymmetric) the client. Shouldn’t this say how? (This is just one instance of a rather pervasive issue.) Grüße, Carsten __

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

On Feb 18, 2018, at 08:35, Hannes Tschofenig wrote: > > Hi Carsten, > > We should maybe add that this information is provisioned either during > manufacturing, via a commissioning tool or some other mechanisms. Not sure > whether this will indeed add more but it might be useful to know. For a

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

ves as another layer of quality control for us). I don’t know why we have to be shy about this specific area for building blocks. Grüße, Carsten > > Ciao > Hannes > > -Original Message- > From: Carsten Bormann [mailto:c...@tzi.org] > Sent: 18 February 2018 17:45 >

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

On Feb 20, 2018, at 08:43, Hannes Tschofenig wrote: > > IMHO the biggest problem with "onboarding" is that people create new terms > without specifying what they actually mean and thereby fail to see the > relationship with existing work. Right. I have no idea what client registration has to

[Ace] Constrained Node/Network Cluster @ IETF101: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF101. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. SUIT is now on top of CORE (!??). (Also, ICE has moved.) The painful ones this

Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig wrote: > > I am curious whether it would be possible to ask for early media-type > registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 There already are registered. I think you are talking about getting Conten

Re: [Ace] Early media-type registration for EST over CoAP

ing about the Content-Format numbers for them. > Would rt="ace.est" be the parameter you are talking about? > > Ciao > Hannes > > -Original Message- > From: Carsten Bormann [mailto:c...@tzi.org] > Sent: 15 May 2018 11:45 > To: Hannes Tschofenig > Cc: a

Re: [Ace] Early media-type registration for EST over CoAP

Forgot to add another example: the content-format numbers for COSE have parameters. Sent from mobile > On 16. May 2018, at 12:26, Carsten Bormann wrote: > > I was thinking about media type parameters such as charset="utf-8". The RT > value need to be registered separ

Re: [Ace] Early media-type registration for EST over CoAP

this on core-paramet...@ietf.org so we get the needed input from the designated expert. Grüße, Carsten > > Ciao > Hannes > > From: Carsten Bormann [mailto:c...@tzi.org] > Sent: 16 May 2018 12:30 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace]

[Ace] New Version of draft-fossati-core-multipart-ct-04.txt

In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed to introduce a media type for efficiently combining multiple representations, along with the Content-Format numbers of their media types, into a single representation. I believe we have needed such a media type in other pl

Re: [Ace] How to specify DTLS MTI in COAP-EST

Hi Michael, On Jun 7, 2018, at 01:32, Michael Richardson wrote: > > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, Sounds good to me. > but we aren't sure that the WG will like us to use so many > words as IPsec to say so. Can we just reference those words?

Re: [Ace] How to specify DTLS MTI in COAP-EST

On Jun 7, 2018, at 18:30, Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? That describes the status of mid-2016. Can we do something forward-looking? Grüße, Carsten ___ Ace mailing list Ace@ietf.org htt

Re: [Ace] How to specify DTLS MTI in COAP-EST

We had that discussion at the SUIT hackathon earlier this week, as well. To get actual interoperability there, of course, every test pair needs to decide between P-256 and 25519 (and, maybe, use hash-based instead; but that is more appropriate for firmware update than for other uses). The genera

[Ace] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a pers

Re: [Ace] [core] Early media-type registration for EST over CoAP

; Sent: 24 May 2018 15:55 > To: Carsten Bormann > Cc: Hannes Tschofenig; core; ace@ietf.org > Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP > > Ok, I will raise the experts to-morrow. > > Peter > > Carsten Bormann schreef op 2018-05-2

Re: [Ace] [core] Early media-type registration for EST over CoAP

On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > > Since the registry that we are registering into does not fulfill the > preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn’t awake enough. If we go for the 256- space, of course it does. And we probably do.) So we’l

Re: [Ace] [core] Early media-type registration for EST over CoAP

On Jun 19, 2018, at 16:33, Michael Richardson wrote: > > We have already had some round trips and document changes thanks to Klaus > Hartke. Yes, but the IANA considerations section currently still has multict in it — that might confuse IANA. Grüße, Carsten __

Re: [Ace] [core] Early media-type registration for EST over CoAP

Hi Michael, On Jun 20, 2018, at 21:39, Michael Richardson wrote: > > The multipart response is only need for systems where the private key will be > generated on the EST server: and a number of implementers are keen *not* to > do that, so the multipart is not urgent to as many people. That is g

[Ace] Constrained Node/Network Cluster @ IETF102: FINAL AGENDA

I forgot to send the update of my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The only change from the previous draft agenda (apart from

Re: [Ace] Review Comments on -03

Hi Jim, > On Jul 15, 2018, at 20:48, Jim Schaad wrote: > > * It is too bad that we don't have the generic coap schemas defined yet so > that we can use that as part of the URL returned with an access denied > response. Can you expand on that? What should we have defined? Grüße, Carsten _

Re: [Ace] Review Comments on -03

On Jul 16, 2018, at 08:26, Jim Schaad wrote: > > In the event of an unauthorized, the RS has the ability to return a URL to > the AS it knows about. If it returns coaps://AS/token, then this might be > thought of implying that one needs to use dtls to talk to the AS rather than > using OSCORE

[Ace] Constrained Node/Network Cluster @ IETF103: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF103. Remember that there is still quite some potential for changes. cbor/teep and 6tisch/suit are annoying but probably livable. No qirg for core goers... All times are ICT (Indochina Time) == UTC +7 hours. There is no

[Ace] Updating draft-ietf-ace-actors for Bangkok

During processing the framework and profiles drafts, it became clear that we do need the architectural considerations written up in draft-ietf-ace-actors. While we had to put all energy into the solutions documents so far, we now have an opportunity to fix the informational document as well. S

[Ace] Constrained Node/Network Cluster @ IETF103: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF103. A few changes from the DRAFT AGENDA. I waited a bit with sending this as a few more side meetings have become known, as well. Of course, "FINAL" doesn't mean final. cbor/teep and 6tisch/ace (was suit) are annoyi

Re: [Ace] Updating draft-ietf-ace-actors for Bangkok

Done: Htmlized: https://tools.ietf.org/html/draft-ietf-ace-actors-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-07 Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.txt

On Oct 22, 2018, at 20:49, Jim Schaad wrote: > > I did not like the idea of using key identifiers when linking together CWTs > for authorization purposes. Right, they are not very useful as they don’t say anything about the authorization information that is attached to that key in a specific

Re: [Ace] WGLC for draft-ietf-ace-authz

+1 for making all the CWT-like structures into real CWTs. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-authz

ote: > > Carsten Bormann writes: > >> +1 for making all the CWT-like structures into real CWTs. > > Not every key/value-pair encoded as CBOR is automatically a CWT. What > happens here is that we are trying to force every protocol element that > is required to solve an applicatio

Re: [Ace] WGLC for draft-ietf-ace-authz

On Oct 25, 2018, at 19:41, Michael Richardson wrote: > > OAuth claim statements too confusing Indeed, there is a problem there (as with many things inherited from OAuth). We might want to fix those issues for the purposes ACE, even if it wasn’t in the domain for the ANIMA work. Grüße, Carsten

Re: [Ace] [T2TRG] Minimizing overhead of certificates in constrained IoT

Much of this discussion is less of a technical nature but about framing things right. If all signed assertions are called certificates, it may be hard to get rid of X.509, because that is what people think of when they say “certificate". What signed assertions do we need for constrained IoT, an

Re: [Ace] Idnits on draft-ietf-ace-cwt-proof-of-possession-05

On Nov 30, 2018, at 17:50, Roman Danyliw wrote: > > /protected header / h’A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/, You may want to switch to the << … >> form: > /protected header / << { /alg/ 1: 10 /AES-CCM-16-64-128/ } >>, Grüße, Carsten ___ Ac

Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile

On Jan 31, 2019, at 01:34, Jim Schaad wrote: > > 1. Please update the text for MUST/SHOULD/MAY to include the language from > RFC 8174. (Public service announcement: If you use kramdown-rfc, just say {::boilerplate bcp14} and that is taken care of, including the all the references needed.) G

Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

> On Feb 18, 2019, at 15:59, Sebastian Echeverria > wrote: > > Hello, > > I have a short comment about error responses from an RS in > draft-ietf-ace-oauth-authz-21. More specifically, my question is about > section 5.8.2. In the second paragraph, it states “The response code MUST be > 4.

Re: [Ace] Embedded Content Types

On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) wrote: > > If we broke the requests to different URIs, it means that a client needs to > keep track of his transactions and on top of it he needs to correlate the key > and the cert he receives at a later time. I think this is just a misu

Re: [Ace] Embedded Content Types

On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > I am thinking of two different URLs, that is not do the difference by a query > parameter but by changing the URI. Note that the query parameters are part of the URI, so fundamentally there is no difference between putting the info there or in t

[Ace] To Panos

Panos: Please give me an email address for you that I can reach. (Sorry for multicasting this.) Grüße, Carsten - The following addresses had permanent fatal errors - (reason: 550 Connections from mailhost.informatik.uni-bremen.de (2001:638:708:30c9::12) are being rejected du...e

[Ace] Constrained Node/Network Cluster @ IETF104: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF104. Remember that there is still quite some potential for changes. cose/teep and lpwan/t2trg are some annoying conflicts that meet the eye. I also don't like that I'll have to miss the cacao BOF (vs. core), dinrg/suit,

Re: [Ace] [T2TRG] Constrained Node/Network Cluster @ IETF104: DRAFT AGENDA

On Feb 23, 2019, at 05:59, Carsten Bormann wrote: > > > Here is my usual eclectic condensed agenda based on the DRAFT AGENDA > for IETF104. Remember that there is still quite some potential for > changes. And how could I forget: FRIDAY, March 22, 2019 — Fri 0930–1800 T2T

[Ace] Constrained Node/Network Cluster @ IETF104: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF104. Remember that, even though this will now go to the printers, there is still some potential for changes. The somewhat annoying coflicts cose/teep and lpwan/t2trg remain. I also don't like that I'll have to miss the c

Re: [Ace] [core] Pub Sub and multicast

I’m certainly interested. Not sure I understand “ • Additionally, the Subscriber must be authorized to subscribe, otherwise an attacker could DoS external nodes that do not want to receive the publications”. Whether the attacker is authorized to subscribe and whether the actual notification re

[Ace] draft-bormann-core-ace-aif-06 - An Authorization Information Format (AIF) for ACE

As requested during the IETF104 meeting, I resubmitted > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > Maybe this would be a good time to consider whether ACE can make use of this? Grüße, Carsten _

Re: [Ace] [Technical Errata Reported] RFC8392 (5710)

(Resending to ACE list with recipient list trimmed.) > On Apr 29, 2019, at 18:40, Carsten Bormann wrote: > > On Apr 29, 2019, at 18:15, Felipe Gasper wrote: >> >> In JSON, maps are called objects and only have one kind of key: >> a UTF-8 string. In CBOR, any valid

[Ace] Constrained Node/Network Cluster @ IETF105: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF105. Remember that there is still quite some potential for changes. Conflicts that meet the eye: COSE/TEEP again! ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. (The poor TEEP people get to both start

[Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA

___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

[Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF105. Remember that, even though this will now go to the printers, there is still some potential for changes. Conflicts that meet the eye: COSE/TEEP stays; ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying.

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

On Jul 30, 2019, at 19:10, Jim Schaad wrote: > From: Benjamin Kaduk > > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks for > readability". > > [JLS] I don't believe that this disclaimer needs to be p

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: > > As far as I gather from the comments (especially from Carsten), we'd solve > this by referencing section 6 of RFC 7049. I will consult with my co-authors, > but I think this is the right solution. That is not what I said. Grüße, Carsten si

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) and data format. COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS. Grüße, Carsten > On Oct 2, 2019, at 14:00, Cigdem Sengul wrote: > > Hello all, > > I am trying to implement this disc

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

On Oct 3, 2019, at 08:42, Hannes Tschofenig wrote: > > but for HTTP we decided to do the work on OAuth, where it got stuck because > the IoT-interested people are not there and the Web folks want something else. …so should we organize a mass-walkin of the ACE people at the OAuth meeting in Ban

[Ace] Constrained Node/Network Cluster @ IETF106: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF106. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (already noted by Russ), BOF on top (thing security): TMRID. ACE/RATS are also both security technologies that i

[Ace] Constrained Node/Network Cluster @ IETF106: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF106. Remember that, occasionally, futher agenda changes do happen. Quite a bit has been moved around from the draft agenda. LAKE no longer conflicts with SUIT, TMRID is now on top of ROLL and TEEP which is maybe a bit le

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote: > >> The statement above >> >> When omitted, they are logically >> assumed to be the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are >> typically used when an endpoin

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > since the Uri-Host and Uri-Port options and whether they should be > omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be

[Ace] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF107. Remember that there is still quite some potential for changes. Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger problem, while the

Re: [Ace] [EXTERNAL] RE: Access token question

On 2020-02-24, at 18:04, Jim Schaad wrote: > > • The proposal from Carsten that has not get adopted anywhere yet. Well, not adopted in the literal sense, but it has been used as a blueprint both in research works and in standardization. The main question that is holding this back from be

[Ace] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF107. Remember that, occasionally, futher agenda changes do happen. Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now on top of 6lo. The other security/not-so-much-security conflicts in the IoT space

Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

On 2020-03-04, at 19:40, Henk Birkholz wrote: > > 1.) go to COSE and ask for a "null signature", https://en.wikipedia.org/wiki/Just_Say_No > 2.) go to ACE and ask for an "unsigned token" option, or > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are > not signed). I

Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

On 2020-03-04, at 23:33, Henk Birkholz wrote: > > Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten ___

Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Jim, > On 2020-03-06, at 20:13, Jim Schaad wrote: > > There is a very high chance that making this change is going to lead one into > a situation where they are going to need to change their because people are > going to start using this tag all of the time and not just when the claims > a

Re: [Ace] [Rats] [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Ned, What I was trying to say is that the Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS. So I wouldn’t call it a token (which implies some form of protection to me). But it is still a useful data structure to carry around. > On 2020-03-06, at 20:59, Smith, Ned wrote: > > Th

Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-04, at 08:42, Seitz Ludwig wrote: > > For the sake of getting the document finished before I die of old age ;-) > would it be possible to specify this in a separate document? I think there may be multiple of these RT registrations, because the fact that a resource is part of an AS i

Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-05, at 06:54, Jim Schaad wrote: > > I have much the same problem. While a client could find an AS which would > authenticate the client, I don't know how the client would establish any > degree of trust in the AS which is going to give it tokens. Hence the four-corner model [1]. G

Re: [Ace] draft-ietf-ace-oauth-authz

ecurity domain, instead of having to do the bootstrapping again and again for each server that device needs to access. Grüße, Carsten > > Jim > > > -----Original Message- > From: Carsten Bormann > Sent: Monday, May 4, 2020 10:38 PM > To: Jim Schaad > Cc: B

Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.txt

> > Comments are very welcome. (1) I can’t parse the binary representation of the String value of ENCODED_TOKEN, which would depend on the used charset. What charset? JSON does not have a charset. (I’m probably misreading this.) What *is* the “String value of ENC

[Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

As I said today, the role of AIF [1] in ACE documents can only be as a suggestion, or as a starting point, because it assumes that the (resource) names are static, and something application-specific has to be added for more dynamic names. The current MQTT proposal [2] is different in three ways

Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

On 2020-05-18, at 17:21, Carsten Bormann wrote: > > [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif Benjamin reminds me that this has -core- as the crucial third word of the draft name. I hope that doesn’t get in the way if we decide to pick this up as an (informationa

Re: [Ace] "default value" for authz-info endpoint

On 2020-06-01, at 11:13, Seitz Ludwig wrote: > > Hi Ben, > > I had a look at the well-known URI list at IANA and it seems that for vanilla > OAuth 2.0 endpoints (authorization, token, introspect) there are no > well-known URI:s either. What exists is an URI used by the authorization > server

[Ace] IANA considerations for authz-info RT

Marco and I still have to do the bike shedding on the actual name (“ace.ai” below), but we can look at my proposed text already anyway: 8. IANA Considerations 8.NN. CoRE Resource Type registry IANA is requested to register a new Resource Type (rt=) Link Target Attribute in the "Resource T

[Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt)

mation Format (AIF) for ACE > Author : Carsten Bormann > Filename: draft-bormann-core-ace-aif-08.txt > Pages : 9 > Date: 2020-06-22 > > Abstract: > Constrained Devices as they are used in the "Internet of Thin

[Ace] Constrained Node/Network Cluster @ IETF108: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF108. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't know what that slot

[Ace] AIF-09 (Re: AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt))

Instead of working on the (great) comments in the reviews, I went ahead and added permissions for dynamic resources. Enjoy: Html: https://www.ietf.org/id/draft-bormann-core-ace-aif-09.html Htmlized: https://tools.ietf.org/html/draft-bormann-core-ace-aif-09 Diff: https:

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On 2020-06-30, at 12:19, Olaf Bergmann wrote: > > NEW: > > All CBOR data types are encoded in canonical CBOR as defined in > Section 3.9 of {{RFC7049}}. This implies in particular that the > `type` and `L` components use the minimum length encoding Note that 7049bis, which has been submit

Re: [Ace] Extended REST model comment

On 2020-06-30, at 16:43, Jim Schaad wrote: > > In trying to formalize a policy for the RD testing, I ended up with > something that I think needs to be noted in this section. There is a > difference between the following statements: > > Access is granted to resources created by the client. > Ac

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

>> >> I would generally prefer to avoid the need for deterministic/canonical >> encoding — is there really a need to re-encode the token? > > There is no need to re-encode the token, and I do not expect that this > would happen if the authorization server has used a finite length. So would we be

[Ace] Constrained Node/Network Cluster @ IETF108: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF108. Remember that, occasionally, further agenda changes do happen. There has been no change from the DRAFT AGENDA in the Conflicts I noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) The only significa

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

On 2020-07-15, at 22:51, Jim Schaad wrote: > > I had been holding off doing an adoption call waiting for a formal request > to adopt it. Sorry about that — I was still thinking we should finish the discussion about the new dynamic permissions. But I realize now that these have been around fo

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

On 2020-07-18, at 00:21, Benjamin Kaduk wrote: > > Refreshing my memory of the WG charter, it seems like this can be in scope, > but we should be sure to consider what analogues already exist in > non-constrained systems, and whether we are in fact creating something > generally new and broadly u

[Ace] Constrained Node/Network Cluster @ IETF109: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF109. Remember that there is still quite some potential for changes. The conflicts that meet the eye this time seem to impact generalists only. Great scheduling job! All times *on my agenda* are in UTC (the default page

[Ace] Constrained Node/Network Cluster @ IETF109: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF109. Remember that further agenda changes can still happen. Very little has changed with respect to the draft agenda. WEBTRANS does meet, and CFRG and IRTFOPEN have been moved around (CFRG now on top of CORE, unfortun

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

On 2020-12-09, at 14:28, Christian Amsüss wrote: > > follow CoRE best practices Indeed; for instance, we “RESTified” documents in ACE before (and they not just became ideologically correct, but also plain better). Grüße, Carsten signature.asc Description: Message signed with OpenPGP

[Ace] Constrained Node/Network Cluster @ IETF110: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF110. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that meet the eye this time are LAKE/RATS, IOTOPS/COSE, CORE/DANISH, in order from hurtful to disastrous (ROLL/SUIT and LPWA

Re: [Ace] I-D Action: draft-ietf-ace-aif-01.txt

I filled in the remaining todos and idnits for ACE AIF. I believe this is now ready for WGLC. Grüße, Carsten > >Title : An Authorization Information Format (AIF) for ACE >Author : Carsten Bormann > Filename: draft-ietf-ac

[Ace] [media-types] ACE AIF media types

The ACE AIF specification makes a number of media type registrations: https://www.ietf.org/archive/id/draft-ietf-ace-aif-01.html#name-media-types-2 Excerpts below. Please review. Grüße, Carsten 5.1. Media Types IANA is requested to add the following Media-Type to the "Media Types" reg

[Ace] Content-Formats for ACE AIF

Together with a few media types, ACE AIF registers two content-format numbers. https://www.ietf.org/archive/id/draft-ietf-ace-aif-01.html#name-content-format Excerpts below. Please review and assign content-format numbers. Grüße, Carsten 5.3. Content-Format IANA is requested to register

[Ace] Constrained Node/Network Cluster @ IETF110: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF110. Remember that further agenda changes can still happen. A number of changes have been made with respect to the draft agenda. CBOR has moved to Monday into what was ASDF's slot, and ASDF is now on top of IOTOPS (ug

Re: [Ace] WGLC for draft-ietf-ace-aif

Olaf and Marco (and Alexey over on the media-types mailing list), Thank you for your comments. I have submitted an updated version that should address these comments. Please do have a quick look. A few comments on the comments: Re Marco’s comments: > * s/Constrained Devices/Constrained devices

Re: [Ace] [media-types] ACE AIF media types

Hi Alexey, On 2021-02-13, at 16:16, Alexey Melnikov wrote: > > This mostly looks fine, but the registration templates are missing some > required and recommended fields from the template. Please review and update. Thank you. I seem to have missed pointing to the update. https://www.ietf.org/a

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

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 >

Re: [Ace] Ordering Guarantee in CoAP-EAP

Hi Ben, we discussed this in the ACE meeting yesterday. 2.01 actually is the right response code for creating a new resource, indicating the advance in the application state (HATEOAS). The name of the new resource could be indicated via Location-Path/Location-Query, and would be sent in the next

Re: [Ace] Reviewing ace-aif

Hi Christian, It seems I haven’t looked at this for a while. It’s been two months now 🤦‍♂️, so let me try to make some progress: > On 2021-03-11, at 12:28, Christian M. Amsüss wrote: > > Hello Carsten, hello AIF, > > as promised I've had a look at AIF: > > "need to ascertain that other device

Re: [Ace] [EXTERNAL] Francesca Palombini's 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 NEW text attaches the “when” to both arms.) The whole idea of attaching the represent

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

en' to both arms (token encoding and > protocol message payload encoding), but I don't have a strong opinion on > this. If the WG can decide how this should be I will implement. > > /Ludwig > > -Original Message- > From: Carsten Bormann > Sent:

Re: [Ace] WGLC for draft-ietf-ace-wg-coap-eap-02

Hi Mohit, great review! There are a few places where I think you might be overcompensating, or where we actually have found good solutions previously that could be applied here. […] > "The URI of the CoAP-EAP service CAN be set to "/b"? First, > "CAN" is capitalized but it is not in the list o

Re: [Ace] I-D Action: draft-ietf-ace-aif-03.txt

and Authorization for > Constrained Environments WG of the IETF. > >Title : An Authorization Information Format (AIF) for ACE > Author : Carsten Bormann > Filename: draft-ietf-ace-aif-03.txt > Pages : 14

[Ace] Constrained Node/Network Cluster @ IETF111: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF111. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LAKE/RATS, IOTOPS/RATS (and there is likely to be an IoT-relevant discussion at tsvwg,

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

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 s

  1   2   >