On Thu, Sep 29, 2016 at 1:50 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> > This also makes sense. I think URIs make more sense, rather than >> defining a new namespace. And the URIs can contain more information >> about the type. What do other folks think? >> >> > I'm a little confused about the proposal, especially how the URI would > contain more information about the type. Would you mind fleshing this out > a bit? > > Something like this: > > Servers that create authorization objects with a non-standard type should > provide a URL as the type string. This allows non-standard types to be > created in a well-defined namespace, to avoid conflicts. Visiting the URL > in a web browser should result in a human-readable web page describing the > non-standard authorization type. > > However, I'm very open to other suggestions! > Well, I guess I have two thoughts here. The first is that if we do want to shift to URIs, then we should move DNSname to also being a URI (a URN at IANA or an IANA registry entry). If the client recognizes it, then it doesn't need to dereference the page, as the content is guaranteed to be the same (especially so in the case of URNs), but it is getting the same sort of identifier for standard and nonstandard types. But I'm not sure that this is the right direction, as I worry that we might lose interoperability over time. For out-of-band authorizations, I think we could use a single common type and an additional field for dereferencing the out-of-band steps. But for new general mechanisms, it would be useful if the client knew from examination whether it could or should use the authorization type. If service A and service B use different URIs for the same mechanism, you have the possibility of a client not recognizing that it can use service B. Imagine for a second that someone creates a method to use an entry in a block chain as an authorization mechanism; if more than one service wants to use the method the 2nd and later either have to refer to the type using the first's URI or making up new URIs that aren't automatically recognized by clients built in response to the first. I agree with the need to collision, but I'm not sure that we have likely collisions unless we try to differentiate each out-of-band set of steps into types. That doesn't seem that useful to me, personally. Just an initial reaction, Ted
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
