What resource directory attributes are used to communicate AS to be used?

[jimsch]

Section 5.1 says that you can asked the RD rather than the resource to get the AS information, where is this placed in the RD? Is it assumed that only one AS is found? Are there resource types which correspond to an AS?

[LudwigSeitz]

We haven't considered that point yet. I would expect that you could define resource types in RD that hold security information about a resource. I noticed you looked into the RD draft, do you have any suggestions?

[jimsch]

I don't know that this is a good idea or not, I understand why you want to do it, but putting an additional "as:URL" into every such resource does not seem to be a good idea for sizing as most people don't want it most of the time. Not sure that doing the RD lookup is a correct answer and if there is more than one AS in the system them you cannot just assume that getting the list of AS endpoints is going to be the right thing to do either.

[LudwigSeitz]

This clearly warrants more thought, and input from someone with better knowledge of the RD RFC. I'll reach out to CoRE.

[LudwigSeitz]

See thread on the CoRE ML

[LudwigSeitz]

Ask Christian Amsüss for feed-back

[chrysn]

The RD should primarily contain data that could just as well be expressed in .well-known/core. When web links are concerned, neither per se directly allows broad-matching statements like "For all resources that match X, it is true that X is authorization-managed-by ".

For individual resources, that can easily be stated; Carsten's example (<coaps://security.example.com/as>;rel=authorization-managed-by;anchor="/s/temp";ace-profile="oscore") seems to show the right way here, and I'd like to start off there -- but as you noted, we don't want to have such a statement mechanically replicated for every single discoverable link.

(On a side note, and if that's not already set in stone, it might be worth considering that scheme for error messages as well. There'd be no need for a dedicated application/ace+cbor format if the response to an underauthorized request could be "4.01, Content-Format:application/link-format, payload: <coaps://security.example.com/as>;rel=authorization-managed-by;ace-profile="oscore">". I don't understand what the nonce actually does, but it can possibly fit in there too.)

If such a link expresses what you want to express, there remain two challenges:

• Many-resources statements. I'd go about this by defining an additional link relation, say rel-auth-managed-by that is defined to mean for any resource X, Y, Z: "(X rel Y) and (X rel-auth-managed-by Z) => Y auth-managed-by Z". It would be up to the client to either discover a auth-managed-by or a rel-auth-managed-by and identify that Z as the authorization server. Whether that rel is convenient to be "hosts" or whether we should pick another link relation for that depends on whether we expect hosts where all resources are managed by a single AS, or whether we expect groups of resources on a host to be.

  Example .well-known/core file:

  </temp>;if="core.s",</hum>;if="core.s",
  <coaps://security.example.com/as>;rel=host-auth-managed-by;ace-profile="oscore"
  

  As <> hosts </temp> (by the default value of rel) and <> host-auth-managed-by <coaps://..>, the client can infer that </temp> auth-managed-by <coaps://...>. Granted, that sounds a bit like puling RDF reasoning in (which is where the approach comes from), but in firmware, no such reasoning would happen, there'd just be two patterns to match for the discovery of an AS instead of one.

• Discovering that efficiently through the RD

  An RD could easily keep and provide all the links for the above, but in a typical discovery step like GET /rd-lookup/res?if=core.s, it would not volunteer that information, and the client would need to query again for any related auth-managed-by relations, possibly twice (for auth-managed-by and host-auth-managed-by). The RD provides extension an extension point that could be used to ask directly for those additional links, and I'd be happy to draft that extension, but let's discuss whether this scheme as a whole can work out. (Note to future self: GET /rd-lookup/res?if=core.s&follow=auth-managed-by&follow=host-auth-managed-by maybe)

[jimsch]

Ludwig is going to be off email for the next couple of weeks.

• In terms of the error message being returned, the format for the 4.1 Unauthorized error is fixed by OAuth and thus we can't change it. It is interesting because I have just been using the content type of application/cbor. I have created an issue on this.

• The nonce is a replacement for having a wall clock that is somewhat synchronized with the world. My expectation is that any RS which needs to provide a nonce would never advertise these links as it needs to provide that freshness indicator to be reflected back. For this discussion I think it can be ignored.

• My expectation is that there are going to be resource servers where every thing is authorized by the same ACE server. I also expect that there will be resource servers where one needs to state this no a resource by resource basis. An example of the later would be a pub/sub server.

• Can you expand on the transitive expressions for auth-managed-by? I am not sure what type of relation you think would show up in the first half of that expression. The host-auth-managed-by makes sense to me as a concept. I don't like the string but auth-managed-by-all would allow for a single query with a wild card which might make up for the lousy name.

[chrysn]

Ad transitive expressions: We have no expression for wildcards or for-all-resources-here statements in link-format. We could of course mint a relation that says "From a <coaps://.../as>;rel="auth-managed-by-all" statement in .well-known/core you may deduce that any resource with the same IP address is managed by that". I find it clearer to not talk of "all resources on that server", because that taps into the structure of URIs which should be treated as as opaque as possible by applications, and causes headaches in connection with alternative addresses.

My proposal is therefore to use other statements about the resources and link via those. We could mint a new link relation, like "shepherds", so that we'd publish

</temp>;rel="shepherds";anchor="/local-dog",
</hum>;rel="shepherds";anchor="/local-dog",
<coaps://security.example.com/as>;rel="sheperd-auth-managed-by";anchor="/local-dog"

("The local dog shepherds both /temp and /hum, and gets-its-sheep-auth-managed-by that AS").

and then the client would first look up whom /temp is shepherded by (/local-dog), and then use its knowledge that "if X is shepherded by /local-dog and /local-dog has a sheperd-auth-managed-by address, that address provides tokens for X".

Now that only really pays off if the statements about shepherding and the local dog are cheap in the RD and .well-known/core. Thus, we don't introduce a local dog, but use the "hosts" relation to the host's / (or /.well-known-core if you believe in an RFC6690bis, point is: it doesn't really matter) resource, and a hosts-auth-managed-by. The amendment to an existing </temp>,</hum> .well-known/core document is quite minimal:

</temp>,
</hum>,
<coaps://security.example.com/as>;rel="hosts-auth-managed-by"

which expands by the default values to roughly

</temp>;rel="hosts";anchor="/",
</hum>;rel="hosts";anchor="/",
<coaps://security.example.com/as>;rel="hosts-auth-managed-by";anchor="/"

("There's a thing that hosts both /temp and /hum, and it gets-all-its-hosted-resources-managed-by that AS").

and thus gives us a clean two-step statement about any resource announced by the host, without using any terminology like "on the same network address" that would lead to URIs being manipulated in unbefitting ways.

[jimsch]

Just so I can make sure that I am clear on this, it could be expanded as the follows

</temp>;rel="shepherds";anchor="/local-dog",
</hum>;rel="shepherds";anchor="/local-dog",
</fido>;rel="shepherds";anchor="/robot-dog",
<coaps://security.example.com/as>;rel="shepherd-auth-managed-by";anchor="/local-dog",
<coaps://secruity2.example.com/as>;rel="shepherd-auth-managed-by";anchor="/robot-dog"

This would be how I could have a second resource of the same ilk which is managed by somebody else.

[chrysn]

Precisely.

The question remains open whether we'll often want to group things to warrant having a dedicated shepherds relation, whether grouping-by-hosts is good enough for the common cases, or whether we it is feasible on constrained devices to call the relation to the AS "auth-managed-by-rel.X" to follow a relation X and expect them to understand that for all X. (Personally, I think working on hosts might suffice, and nothing stops one from adding something generic like shepherds later.)

[jimsch]

I would agree that doing grouping-by-hosts is sufficient for the present time.

[LudwigSeitz]

This should go into a separate draft. Closing.