> -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Francesca Palombini > Sent: Tuesday, June 23, 2020 6:45 AM > To: Carsten Bormann <c...@tzi.org>; Ace Wg <ace@ietf.org> > Cc: Marco Tiloca <marco.til...@ri.se> > Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core- > ace-aif-08.txt) > > Hi Carsten, > > Thanks for this quick update! Just some short high level comments, to make > sure we can use this for ace-key-groupcomm-oscore. > > In ace-key-groupcomm-oscore, we would say that Toid is the identifier of the > OSCORE group, so the OSCORE "group name", which is encoded as a bstr. For > Tperm, it's a bit further away from what the aif document specifies (which is > why I want to check with you), but we would go for array of tstr, since we > can't > really encode the permission to be a "monitor" node (for example) by > indicating a REST method. This is a bit stretched from the document right now, > but it should work. > > We would have to register a media type (and content format) for this, so what > would this be? You use aif+cbor for the default, so maybe something like "aif- > ace-group+cbor". For section 5.3, we would have to register Toid and Tperm > with something like: > > Toid registry: > * name: gname > * description: group name of the OSCORE group as specified in ace-key- > groupcomm-oscore > > Tperm registry: > * name: roles > * description: role of the group member as specified in ace-key-groupcomm- > oscore > > I think we are missing some form of "encoding" column in the registries above. > In that case it would be "bstr" for Toid gname and "CBOR array of tstr" for > Tperm role. It would also be "tstr" for local-part Toid and "int" for Tperm > REST- > method-set. (also, minor, but you sometimes use "local-part" and sometimes > "local-uri", see section 4). Even better, the description or the encoding in > the > registry could point to "path" and "permissions" cddl, for the default values > in > the aif doc. > > Using "array of tstr" for roles allows us to express what we need for "set of > roles". I don't see this being in contrast with the aif document right now.
This follows what I would expect, for MQTT I would see AIF-MQTT = AIF_Generic<filter, permissions> filter = tstr permissions = [ +permission ] permission = "publish" / "subscribe" For the group comm draft, I think that AIF-GROUP-COM = AIF_Generic<path, permisions> path = tstr ; group name permissions = uint . bits methods methods = &( requester = 1, responder = 2, monitor = 3, verifier = 4 ) This does require a registry if we ever expect this to grow. > So all in all, I think this can work for ace-key-groupcomm-oscore. Please let > me > know if you see anything that bothers you in my summary. > > Thanks, > Francesca > > On 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann" <ace- > boun...@ietf.org on behalf of c...@tzi.org> wrote: > > I went ahead and quickly implemented what we had discussed today. > > https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html > > Lots more editing to do, but the gist of what I was trying to say should > be > there. > Comments welcome! > > Grüße, Carsten > > > > On 2020-06-23, at 00:12, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Authentication and Authorization for > Constrained Environments WG of the IETF. > > > > Title : An Authorization Information 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 Things" need > > security. One important element of this security is that devices in > > the Internet of Things need to be able to decide which operations > > requested of them should be considered authorized, need to ascertain > > that the authorization to request the operation does apply to the > > actual requester, and need to ascertain that other devices they place > > requests on are the ones they intended. > > > > To transfer detailed authorization information from an authorization > > manager (such as an ACE-OAuth Authorization Server) to a device, a > > representation format is needed. This document provides a suggestion > > for such a format, the Authorization Information Format (AIF). AIF > > is defined both as a general structure that can be used for many > > different applications and as a specific refinement that describes > > REST resources and the permissions on them. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-bormann-core-ace-aif-08 > > https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-bormann-core-ace-aif-08 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > i-d-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace