> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Francesca Palombini
> Sent: Tuesday, June 23, 2020 6:45 AM
> To: Carsten Bormann <[email protected]>; Ace Wg <[email protected]>
> Cc: Marco Tiloca <[email protected]>
> 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-
> [email protected] on behalf of [email protected]> 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, [email protected] 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
> > [email protected]
> > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
