Skip to content
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

Closed
yaronf opened this issue May 10, 2021 · 5 comments
Closed

What do we mean by AS discovery? #17

yaronf opened this issue May 10, 2021 · 5 comments
Assignees

Comments

@yaronf
Copy link
Contributor

yaronf commented May 10, 2021

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.

@jricher
Copy link
Collaborator

jricher commented May 10, 2021

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?

@yaronf
Copy link
Contributor Author

yaronf commented May 11, 2021

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).

@jricher
Copy link
Collaborator

jricher commented May 11, 2021

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.

@yaronf
Copy link
Contributor Author

yaronf commented May 11, 2021

It's not terrible, but it would mean some information would be duplicated across the two metadata documents.

@jricher
Copy link
Collaborator

jricher commented Feb 8, 2024

I believe this has been addressed by updates to section 3.1, and this issue will be closed.

@jricher jricher closed this as completed Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants