Re: [hrpc] [Iotops] Authorization for IoT devices

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

~snip!
    Hannes> OAuth: Some of those scopes have been standardized.

Michael: Thank you for confirming my understanding.
Michael: I'm looking for a standard for the rules.
Michael: Why? because auditing, because humans need to understand them, because configuring the rules needs to be something non-experts can do.

Here are some examples on what has been standardized:

Section 5.4 of the OpenID Connect Core specification defines a few scope values related to identity management:
https://openid.net/specs/openid-connect-core-1_0.html

The healthcare specification in the OIDF defines scopes in their "Health Relationship Trust (HEART)" specification:
https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html

More specs of the OIDF from other application domains can be found here:
https://openid.net/developers/specs/

In the OAuth working group we also have some work on scopes as part of the work on rich authorization requests. See Appendix A for examples:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05


    > There has also been an attempt to standardize more generic ACLs,
    > see draft-ietf-ace-aif.

Michael: Not even close, I think.

This is work in progress; so you can suggest changes.
You could push it all the way to turn it into XACML:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml


    mcr> If I'm wrong please correct me.
    mcr> How would ACE-OAuth identify the local Sheriff?

    Hannes> The purpose of an authorization framework is not to identify a
    Hannes> specific person. That's the role of an identity management
    Hannes> framework.

Michael: It's not a specific person, it's a specific role in an particular geography.
Michael: That's why this problem is non-trivial.

This is why you will have to work out standards for certain application domains since otherwise this will get so complex that nobody is going to use it.

    > If you also want to add the identity management piece to ACE/OAuth
    > (which people have obviously done), then you can add OpenID Connect
    > and, for example, FIDO to the mix.

Michael: If we can really do this with those specifications, I'd be interested in knowing how, or seeing an example of a system which has done that.

FIDO has a whitepaper that talks about the interaction between FIDO and identity management technology, see
https://media.fidoalliance.org/wp-content/uploads/Enterprise_Adoption_Best_Practices_Federation_FIDO_Alliance.pdf
https://fidoalliance.org/fido-and-federation-protocols-tech-note/

FWIW we, as part of Pelion, even have a product doing this for IoT use cases. I blogged about it a while ago:
https://community.arm.com/developer/research/b/articles/posts/mbed-secure-device-access-enhancing-iot-device-management-with-user-authentication-and-fine-grained-access-control
Here is some more info about the product called "Secure Device Access":
https://developer.pelion.com/docs/device-management/v4.1/sda/index.html

Michael: I'm actually convinced that we don't need a lot of new work ("new ingredients") to make things go, but I think that we need a clear architecture on combining existing work ("better recipes")

That would obviously be good.

Ciao
Hannes

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
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.