New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What do we mean by AS discovery? #17
Comments
It's possible that we could use the same OPTIONS request to the grant creation endpoint that the client instance uses, but then we have the problem of leaking RS-facing information and client-facing information in the response. A thought: The client instance doesn't really :need: to do discovery with how the protocol is structured, but an RS is going to want to have a few different bits of information -- different endpoints, options, and features. It does raise an interesting question though: what if there were more of a cohesive AS-RS protocol that drove all of these interactions? An RS could then get all the other bits "inline" just like the client does. Does that even make sense, though? |
I think a single "metadata" endpoint for both Client-facing and RS-facing information makes sense, because the AS is a single architectural component. And all of this information should be public (i.e. the returned information does not depend on the caller's identity). |
I disagree with that reasoning -- the client-facing and rs-facing aspects of the AS are architecturally separate, and mixing them could lead to confusion. For example, if the AS advertises token formats for the RS's it protects, it implies (incorrectly) that this is information a client instance would need to care about or have any say in. While they could be in separate sections of the same document or something like that, I am personally leaning towards things being separated even more fundamentally. |
It's not terrible, but it would mean some information would be duplicated across the two metadata documents. |
I believe this has been addressed by updates to section 3.1, and this issue will be closed. |
AS Discovery: why do we need a "well known" URI? Either we use GNAP Core to pass the AS address to the RS, and then we could pass a full URI, or we don't, and then how does the RS even know how to find the AS?
On second thought: maybe this makes sense, but should simply be renamed "AS capability discovery". I.e., you don't "discover" the AS. Once you have the AS's address, you can discover its capabilities.
Also, I'm not clear if the AS Grant URI belongs in this document.
The text was updated successfully, but these errors were encountered: