Hi Carsten,
My understanding about the model is: a URI is associated with a set of access
permission. Correct?
If we want that different Client has different access permission to a resource,
e.g. node A is allowed to GET/PUT /6t/cellList in node C, but node B is only
allowed to GET /6t/cellList in node C, how should we express it?
ThanksQin
On Friday, May 8, 2015 2:03 AM, Carsten Bormann <[email protected]> wrote:
I need to catch up on the details of this thread, but indeed, ACE is
chartered to do authorization. What exactly you need in terms of
granularity may be application specific, so at some point the ball may
be played back to 6tisch to identify the specific information required.
A strawman for such an authorization information format is in
http://tools.ietf.org/html/draft-bormann-core-ace-aif-02
With the example:
[["/s/light", 1], ["/a/led", 5], ["/dtls", 2]]
This is essentially a list of pairs of paths and permission bits.
(The spec for is in CDDL, not in YANG, but should transfer easily:)
authorization-info = [* authorization]
authorization = [
path: tstr,
permissions: uint .bits methods,
]
methods = &(
GET: 0
POST: 1
PUT: 2
DELETE: 3
PATCH: 4
)
Grüße, Carsten
Thomas Watteyne wrote:
> Can anyone shine a light on whether ACE is handling all of Kris' concerns?
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
