> On 26 Jun 2019, at 17:34, Michael Richardson <[email protected]> wrote: > > Signed PGP part > > Eliot Lear <[email protected]> wrote: >>>> In either case, right now the administrator has to manually know and >>>> populate information, to say - some device 1.2.3.4 is a controller, >>>> either for MUD URL https://example.com/mud <https://example.com/mud> or >>>> a class http://example.com/mudclass1 <http://example.com/mudclass1>. >>>> That can be laborious. To assist, we are examining ways to have a >>>> controller declare itself as a candidate controller. That at least >>>> provides a hint to the administrator that this particular device is >>>> capable of serving in a particular role. >>> >>> I think that anything that requires administrator activity to be a fail for >>> residential use. It's too complex. > >> There will ALWAYS be a need for an administrator in the enterprise >> case. But maybe with the options above we can ease the consumer burden >> over time. In the consumer case, you might want an app for initial >> device admission control anyway, no? Can we not rely on that >> interaction as an approval step in this instance? > > I think we'd all like to have a generic app (with an RFC standard API) that > can onboard any device and can do admission control for any controller. > I think this is what you are saying as well.
Yes, but I was saying a bit more. Do you expect to fully automate the inclusion of a controller into a controller class in the home? How do you envision the full flow looking like? > >>>> One possibility to address this is to incorporate the new RESTful >>>> endpoint into an ANIMA BRSKI join registrar, which may already be >>>> exposed. But that requires that ANIMA BRSKI be in play, which it may >>>> not. > >>> It is, however, a really good idea for the case where it is in play. >>> >>>> My thinking is that we do this work in two stages. First handle the >>>> easy case, which is the MUD file extension, and then figure out how to >>>> do the app version of this. >>> >>>> Thoughts? >>> >>> yes. >>> > >> Was that “yes” to the two stage approach? > > "Yes" :-) Okidoke. > > Eliot Lear <[email protected]> wrote: >>> 1) insist that to user the my-controller connections that the two devices >>> have to be signed by the "same" entity. ["same" could mean literal the >>> same key, the same certificate Issuer/DN, or something more complex] >>> >>> 2) we could have devices declare in an MUD extension the >>> DN/certificate/entity which must sign their controller device. >>> >>> 3) (2) above, but with some level of indirection through some URL. > >> Another thought here: > >> We could provide a level of dereference for authorized controllers in >> the device’s MUD file, in the form of a URL list that would look >> something like: > >> { [ >> “controller” : “controller-name" >> “mud-urls” : [ some mud urls of valid controllers here ] >> “include” : “https://levelofindirection.example.com” that points to a file >> that contains a JSON serialization of this grouping >> } > > yes, this is exactly what I was thinking about. > > Would "mud-urls" / "include" be mutually exclusive? I don’t see why it would have to be. But now let’s back up, just to make sure we’re not digging too deep a hole for the application case that Ranga wants to get to. If the MUD protected device is declaring MUD URLs for MUD controllers and that is what all of this would boil down to, then the app case is really a completely separate mechanism, because apps don’t have MUD-URLs. If we do a two-stage, then we need a completely separate draft for apps anyway, but I was hoping for some commonality. Eliot > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
