Is a Solid client on an Arduino Uno achievable? about authentication-panel HOT 11 CLOSED

+1, this is a great topic. And as you can imagine, everybody who wants to do something with constrained IoTs bumps up against this. I'm sure we'll discuss this in more detail, but I want to add two quick links:

• On the practical side: the ongoing work over at the Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework working group.
• On the academic side: A Survey of IoT Authentication Schemes paper.

from authentication-panel.

I wonder if this conversation wouldn't fit better on https://forum.solidproject.org/
Otherwise we should add some clear acceptance criteria for resolving this issue.

from authentication-panel.

Agreed interesting topic. It might be solved with something as simple as a client-credentials grant where you would share your credential secrets with the IoT device and it could automatically authenticate.

Though, if you don't want to share your credentials with it, then it becomes a bit more complicated. It could possibly send a notification to your Pod that would open a window on your personal device to allow it to authenticate.

from authentication-panel.

Agreed interesting topic. It might be solved with something as simple as a client-credentials grant where you would share your credential secrets with the IoT device and it could automatically authenticate.

Yeah, but the thing is that I want to give it a URI too, and use that URI to set acl:Authorizations for it.

Though, if you don't want to share your credentials with it, then it becomes a bit more complicated. It could possibly send a notification to your Pod that would open a window on your personal device to allow it to authenticate.

Yeah, but what I had mind was actually that you didn't give it your credentials, but you could, under your own pod, give devices URIs, and then generate credentials to authenticate that URI... Something like that.

from authentication-panel.

you could, under your own pod, give devices URIs, and then generate credentials to authenticate that URI

Could you go into more detail on the step-by-step for that?

from authentication-panel.

Perhaps, it is a very loose thought, so more a braindump than a step-by-step, but here we go:

1. An app that is authenticated as a normal user creates a resource, e.g.

https://iot.example/devices/thermo.ttl

which has some Turtle

<#thing>  a sso:SensorDevice ;
  ex:hasToken <https://iot.example/devices/private.ttl#thermo> .

The latter is a reference to a resource that must be adequately protected, since it contains a secret:

<https://iot.example/devices/private.ttl#thermo> ex:bearerToken "sdgjdsolfgjsoiljfgsdg" .

Just got some inspiration from UNIX' /etc/passwd and /etc/shadow :-) . The owner may then grab the bearer token and set it in the EEPROM of the Arduino for a client to use when authenticating to a Pod.

The URI of the device would be given in the token https://iot.example/devices/private.ttl#thermo, and when dereferenced it will show where the bearer token resides...

But now, I start to realize that the idea kinda falls apart (that's what sometimes happen when you try explain a loose idea), because the server would have to have access to the private file but it can't through the Solid interface, because you can't just have any server access that. It could work if the private file is on the same RS as the resource the device wants to access. But that's just a small subset of what I wanted to achieve here, even though it covers 100% of my current use cases for it...

If we could live with that, then the server would just verify the bearer token against the token on file.

So, it seemed somewhat attractive to have just a shared secret at first, since that could be pretty small, and all you'd need on the Arduino is a string in EEPROM and it wouldn't need to compute anything. But perhaps if it is a public key that sits on the server side, that doesn't need to be protected, and that the Arduino has the private key in the EEPROM?

Now, I should probably not be trying to design these protocols to begin with, but rather leave that to the folks @dmitrizagidulin is referencing. :-) But now that it is written, I figured I might just leave it here, just in case there is some idea that could be useful.

from authentication-panel.

just thinking out loud here...

if your IoT device could do https, how about something like (for the IoT profile):

@base <https://iot.example/bot.ttl> .

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix prov:  <https://www.w3.org/ns/prov#> .
@prefix basic: <TBD> .

<>
	a foaf:PersonalProfileDocument;
	foaf:primaryTopic <#me> .

<#me>
	a foaf:Agent, prov:SoftwareAgent;
	foaf:name "Cool IoT Bot";

	basic:password [
		a basic:PasswordHash;
		basic:audience  "https://server.example/bots/"; # any URI with this prefix
		basic:algorithm basic:sha512;
		basic:hash      "D716A4188569B68AB1B6DFAC178E570114CDF0EA3A1CC0E31486C3E41241BC6A76424E8C37AB26F096FC85EF9886C8CB634187F4FDDFF645FB099F1FF54C6B8C"^^xsd:hexBinary
		# sha512("abcdefg") ^^^
	] .

	# client would send
	#   Authorization: Basic aHR0cHMlM0EvL2lvdC5leGFtcGxlL2JvdC50dGwlMjNtZTphYmNkZWZn
	# (base64("https%3A//iot.example/bot.ttl%23me:abcdefg"))
	# for any URI starting with "https://server.example/bots/".

the password is audience restricted so that, since the plain password is divulged to the audience, it can't turn around and use that password anywhere else.

the IoT device would just need to be configured with its webid and password(s) for its audience(s), assuming its profile is stored somewhere else. this scheme isn't constrained to IoT devices of course.

obviously since the hashed password is in the public profile, a real password used in such a scheme would need to be longer so that brute forcing wasn't feasible.

from authentication-panel.

servers would need to support this Basic scheme too:

WWW-Authenticate: Bearer realm="/auth/", scope="openid webid",
    Basic realm="/auth/", scope="webid"

from authentication-panel.

or, to get the benefits of server-issued access tokens (see #12), my auth proposal could be extended with a "get an access token with basic auth" method, that would otherwise work just like the WebID-TLS token endpoint:

WWW-Authenticate: Bearer realm="/auth/",
    scope="openid webid",
    nonce="j16C4SOLQWFor3VYUtZWnrUr5AG5uwDF7q9RFsDk",
    webid_pop_endpoint="/auth/webid-pop",
    webid_tls_endpoint="https://webid-tls.example.com/auth/webid-tls",
    webid_basic_endpoint="/auth/webid-basic"

from authentication-panel.

@zenomt

if your IoT device could do https, how about something like (for the IoT profile):

I don't think TLS can be assumed. I haven't seen any successful implementations. The Arduino Uno has just 2k of RAM, so you can't even fit a 2048 bit key in there (assuming there are other things than the key)... However, perhaps it is the assumption that you need to have deal with public keys that has made it hard? Could perhaps TLS-PSK make it workable? I really have no idea. I think it is attractive to not need a password too, if a shared key could do.

But yeah, the profile should be stored elsewhere (that's why I'm thinking simply the owner's pod).

from authentication-panel.

This issue is out of scope for the Solid-OIDC panel. If there are particular portions of the specification that make it incompatible with constrained devices, such as an Arduino, a new issue should be created, focused on that particular area.

from authentication-panel.