Hi Carsten, The challenge is that there is not a single way used in deployments. Some of the techniques fall outside the scope of the IETF (such as the manufacturing-related interactions), link layer specific approaches (such as a Blueooth Smart App), or Secure Element-based concepts.
Note that related solutions, such as ZeroTouch, ANIMA, EST, also leave this initial provisioning undefined. I am not saying that nothing should be standardized but it will be difficult to recruit the appropriate expertise and to get the relevant companies to participate. Ciao Hannes -----Original Message----- From: Carsten Bormann [mailto:c...@tzi.org] Sent: 18 February 2018 17:45 To: Hannes Tschofenig Cc: ace Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark On Feb 18, 2018, at 08:35, Hannes Tschofenig <hannes.tschofe...@arm.com> 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 protocol that is meant to be interoperable, there need to be standard (if not MTI) ways of getting this done. At least we need to have a defined interface between CAM (“commissioning tool”) and C for letting C know what was agreed about how to address AS and which RSes it should be used for. Grüße, Carsten IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
