Subject: [core] CoRAL and forms

From: Jim Schaad <[email-masked]>
Date: Fri, 12 Jun 2020 18:00:39 -0700

As I have said before, I think that the links section of this document is
ready to go.  I think that the CBOR encoding dictionary is going to work.
There may be better solutions, but I don't have one and this one is going to
be adequate.  However, I still don't know enough about forms to make any
sort of decisions about the current structure being enough.  My problem is
that I don't believe that the way an IoT device is going to use a form is
the same way that it is used by a browser over HTTP.  Simply because it is a
document that I have read recently, and it is a document that I would like
to see using CoRAL and not links, I will be using
https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin to try and do
some exploration.  

Question #1:  How much do forms as represented in CoRAL and some of the WoT
TD description work that was presented at the T2TRG meeting on Monday.   One
of the statements that was made is that the developer needed to have the
full description of the TD, including possible dynamic changes to it, in
order to write code.  That there was not going to be a good way for an
application to be able to interact with the TD without this level of
knowledge.  I think that this is a true statement for CoRAL forms as well
with the most relevant presentation being that dealing with Hypermedia
Control for WoT.

Question #2: Does this make sense?  Looking at the example given in section
2.5.1 where a get is done on the collection of OSCORE groups.  In addition,
this point can be used to create a new OSCORE group, I think that this would
be presented as a form.  This means you would have

GET /manage

2.05 Content
Content-Format: TBD1 (application/coral+cbor)

#using <http://coreapps.org/ace.oscore.gm#>
#base </manage/>
Item <gp1>
Item <gp2>
Item <gp3>
CreateGroup -> _ [
	group_name _ {optional _ }
	group_title _ { optional _ }
	exp _ { default 3605 }
	active _ { default false }
	as_uri _ { optional }
	aead_alg _ { default 10 }
	hkdf _ { default 5 }
	cs_alg _ { default -8 }
	application _ { optional _ }
]

Some interesting things to note,

1.  Not all of the possible options are presented in the form above.  Some
of the fields can easily be inferred from a second field and thus do not
need to be specified by the client.  An example of this is the counter sign
key information (cs_key_params).  

2.  Given that the set of possible values is not included as part of the
information, while there may be an assumption that the client would know
what the list is, there are some possibilities that are not taken into
account.  First the set of possibilities may have grown since the client was
created and second, the set of possibilities could be restricted by the
server.  One interesting issue is when a list of items if provided is
exhaustive vs recommended.

3.  One of the interesting things that I would not know how to represent, or
if it even should be represented, would be a value of "next GROUP0099" which
would indicate that this is the next value that would be assigned, but it
may not be the one that you get.

Now let's do a create of a new group:

POST /manage

#using <http://coreapps.org/ace.oscore.gm#>
alg 10
active True
group_title "rooms 1 and 2"
as_uri <coap://as.example.com/token>
application "heating"
application "lighting"

2.04 Changed
Location-Path: manage
Location-Path: gp4

#using <http://coreapps.org/ace.oscore.gm#>
alg 10
active True
group_title "rooms 1 and 2"
as_uri <coap://as.example.com/token>
application "heating"
application "lighting"
join_uri </groups/gp4-join>
Update-Group => _ [
	operation PATCH
]
Add-Application => - {
	operation PATCH
               add_app _
}

In the event of an error it might return

4.00 Bad Request

#using <http://coreapps.org/ace.oscore.gm#>
CreateGroup -> _ [
	alg 99 {
		value 10
		value 11
		value 33
	}
]

This provides the parameter it did not like as well as a set of possible
values that could be placed in the location so that the client can know how
to repair the group creation request.

How much of what I outlined even makes sense?  What types of form cases are
people thinking of that I have not covered here.

Jim