Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signing and encrypting body of actual responses of interaction pattern endpoints #118

Closed
MooXo opened this issue Sep 28, 2018 · 2 comments
Closed

Comments

@MooXo
Copy link

MooXo commented Sep 28, 2018

Hi guys,

i am working on implementing of signing and encrypting of payload of device endpoints specified by thing descriptions in our project VICINITY which tries adopt the WoT standard ideas.

I am using JWS and JWE standard to sign and then encrypt actual payloads. This is simple to implement.

However, how i can define specify in Thing description that content of this endpoint is signed and encrypted?

The examples provided in wot-security is about more less the authentication. However we would like to go deep event to encrypting the payload exchanged.

Thanks!

@mmccool
Copy link
Contributor

mmccool commented Oct 1, 2018

You're right, right now we only authentication (per-link if necessary) and protocol-level encryption (https, coaps, etc). What we don't support yet are object security schemes. An example would be COSE, an object security scheme for CoAP. Supporting these is definitely on my list of things to do. I think they can be supported by extending the "security scheme" to support them. So security schemes don't have to just be about authentication, they can also indicate encryption schemes.

I'd like to better understand your scheme and also maybe propose a strawman based on security schemes. For example, if there was a "jwe" scheme that indicated object encryption with JWS/JWE, would that be sufficient? Would any additional parameters be needed? I imagine that there would have to be a key server, so the scheme might have a URL pointing to that.

Then, yes, we really need to go and do the same thing for COSE.

@mmccool
Copy link
Contributor

mmccool commented Nov 19, 2018

The use of "contentType" rather than "mediaType" now allows parameters for object security to be specified (eg JOSE, COSE). So that is how that should be done, rather than as a security scheme.
I'll close this, but we definitely need a test implementation.

@mmccool mmccool closed this as completed Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants