> There is some text that I think could be further improved before
> publishing this as an RFC.
> The following notion appears several times in the document:
>
> However, no authentication framework is provided, which
> limits the policy options available when the "Authorization by
> Access
> Control" model is used.
> There is other work coming from this working group that supports the
> authorization
> by access control model. Is the point of these phrases to highlight
> that other documents
> are needed to make authorization by access control more useful? Or is
> it to note that the
> current tools deployed for authentication over http make authorization
> by access
> difficult.
The intent was to simply highlight an area where a commonplace or reasonable assumption (that identity-based access control is an option) could lead to an unexpected conclusion. HTTP authentication doesn't work until you put in a lot of ground-work: identifying principals, deciding on realms, authentication credentials, trust anchors, and much more. We don't define them here, so it would be dishonest to even give the impression that HTTP authentication is going to work.
Whether or not we ever get to the point that we can reliably use (client) authentication in HTTP, I don't want to speculate.
> As written, I expect readers who have not been following this work
> closely to interpret the phrase to mean that the group chose not to provide a framework and
> thus doesn't
> expect people to use authorization by access control much.
I didn't think that it was a good idea to presume anything about how a specification would be deployed. But your conclusion is the exact one that I would hope that readers take away.
Given the maturity of -policy-uri, it might improve the situation by adding a citation in Section 3.2. That might at least point a reader in the right direction.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
