Anonymous Styles to address custom client styles Maps use cases

[jerstlouis]

In WMS, we had the capability for a client to submit a custom style and retrieve a map.

If client was able to POST a style then retrieve a style resource only available for that particular client from which we could retrieve a map, we would have this capability for OGC API - Maps.

Related to https://github.com/opengeospatial/ogcapi-maps/issues/42.

[cportele]

I don't think this is related to OGC API Styles (that is, the resources specified by the standard)?

[jerstlouis]

@cportele The resource would still be /styles with the main POST method to deploy a new style, creating a /styles/{styleId} resource from which could be retrieved a /styles/{styleId}/map.

Just like for the POST of a MOAW-JSON workflow to /collections to create a virtual collection in Processes - Part 3 (which we're now considering moving towards instead of the /processes/{processId}/execute), I guess the "for the client (who submitted it) 's eyes only" concept can be purely an authentication thing, and that styles, like these virtual collections, can share the same end-point for the client's own use and publication.

However, I think this would require some kind of request header when a client is authenticated and does not mean for the style or virtual collection to be visible to every other user (for their own use only)? Perhaps these are topics for the new OGC API - Common - Security SWG to consider? Something like OAPI-PublicDeployment: false.

[cportele]

@jerstlouis I think I am more confused now. So this is only about access control to styles?

This is orthogonal to OGC API Styles and you can implement that already today with the security schemes / authentication and authorization mechanisms that the API. This is no different from features where some may see new features and others don't, depending on their identity.

I guess any proposed OGC API - Common - Security SWG would look into guidance how to communicate authentication requirements/options of the API? It is not clear to me in how far this requires a SWG or simply informative guidance, but, yes, what you are looking for does not seem to be specific to styles, but to security aspects in general. Can we then close this?

[jerstlouis]

@cportele

So this is only about access control to styles?

Yes and no. The use case is something that was possible with WMS, for which OGC API - Maps relies on OGC API - Styles to deploy a new style, but this concept of being able to create an ephemeral / private resource (which is not specific to Styles), is critical to fill that void.

I guess any proposed OGC API - Common - Security SWG would look into guidance how to communicate authentication requirements/options of the API?

That could be an option, but I think a general request header like I'm proposing could be defined, and then an implementation could support that header or not?

The draft charter for the new proposed OGC API Common - Security SWG being presented this week is here:

https://portal.ogc.org/files/?artifact_id=109420&version=1

Can we then close this?

I think we should discuss / make sure that there's a path forward that something will be defined for this use case to fill that void on an important WM(T)S use case, and that some SWG is taking on this work before we close (or better yet, transfer) this issue (we could transfer to OGC API - Common until the Common Security SWG repo is set up).

In addition to authentication level, there's also the concept of resources "private to me only / potentially expiring in X hours", and the idea that implementations could have that as the default mode for unauthenticated clients (but still with an option to explicitly request this mode even when authenticated as a super-user).

[cportele]

@jerstlouis

As I don't see how this could or should impact OGC API Styles, I still think it should be closed - or moved somewhere else.

I also have doubts about the concept of resources "private to me only / potentially expiring in X hours" in the context of "unauthenticated clients" - at least when we discuss normative statements in a standard and not just some implementation, but I guess that discussion should be in that other SWG.

[jerstlouis]

I also have doubts about the concept of resources "private to me only / potentially expiring in X hours"

To clarify the initial intent of this issue, the use case is specifically what was possible with the SLD standard defining the additional SLD and SLD_BODY parameters extending WMS.

So as an example the request:

GET http://yourfavoritesite.com/WMS?
   REQUEST=GetMap&
   BBOX=0.0,0.0,1.0,1.0&
   SLD_BODY=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3CStyled
LayerDescriptor+version%3D%221.1.0%22%3E%3CNamedLayer%3E%3CName%3ERivers%3C%2FN
ame%3E%3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%3E%3C%2
FNamedLayer%3E%3CNamedLayer%3E%3CName%3ERoads%3C%2FName%3E%3CNamedStyle%3E%3CNa
me%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%3E%3C%2FNamedLayer%3E%3CNamedLayer
%3E%3CName%3EHouses%3C%2FName%3E%3CNamedStyle%3E%3CName%3EOutline%3C%2FName%3E%
3C%2FNamedStyle%3E%3C%2FNamedLayer%3E%3C%2FStyledLayerDescriptor%3E
   WIDTH=400&
   HEIGHT=400&
   FORMAT=PNG

would become an OGC API - Styles POST operation followed by an OGC API - Maps GET operation:

POST http://yourfavoritesite.com/ogcapi/styles
   (SLD media type and payload from SLD_BODY parameter)

GET http://yourfavoritesite.com/ogcapi/styles/myPrivateEphemeralStyle/map?
   f=png&
   bbox=0,0,1,1&
   width=400&
   height=400

and just like no one else but the server would have seen the value of that SLD_BODY, no one else should see this myPrivateEphemeralStyle.

It's the exact same use case for the Processes - Part 3 Private/Ephemeral Virtual Collections. You may want to just test a style / workflow until you're happy with it and intend to deploy it, at which point you want to do a POST operation creating a persistent resource for everyone (and need to be authenticated with sufficient credentials for this), or you may just want the server to do the rendering / processing work for you with no intent to publish the results to others on that server. I think it does need some discussion, perhaps some of the discussion can happen on Thursday in Styles and the rest in the new Common Security SWG...

I still think it should be closed - or moved somewhere else.

We can probably move this to OGC API - Common on Wednesday, but given no shared administrator access of the Styles and Common repo, we might need help from OGC staff :) I don't know if there's an intent to use https://github.com/opengeospatial/ows-security as the repository for the newly rechartered SWG.