I do not have the depth of understanding of OAuth as you guys, so forgive me if I'm missing the discussion completely.
For me this sort of boils down to how we establish trust between the different roles in OAuth. For an API the trust lies between the AS and itself. The API may have no trust in the clients directly, but relies on the AS to provide the user consent, client authentication but also e.g. the use of request objects. At least in my domain, the API might not trust "claims" as parameters in a request from the client, but will trust the "claims" in an access token. In my domain the trust established between the client and the AS is an important part of the ability to interact across security domains. It also provides a way for us to establish domain standards for representing different types of authoritative information. For instance, we have a legal requirement to log certain types of information about the user when exchanging sensitive information. This information is usually tied to a OAuth scope, e.g. "get patient records". The suggested use of "structured_scope" not only gives us an opportunity to convey contextual information that can be shown in the user consent, it also gives us a way of enforcing national domain-specific standards of expressing different types of information tied to the scope (e.g. prescription, sick note, patient records etc) which would make interoperability within the health sector easier. Also, the health sector in Norway has a strict legislation regarding privacy and patient rights,, so we would actually log the issued access tokens with structured_scopes to fulfil some of the legal requirements. Personally I'm not sure what makes more sense, the "structured_scope" or "transaction_scope" name - but "transaction_scope" is more semantically loaded. I also agree with mr. Campbell that the concepts should be treated separately. <mvh>Steinar</mvh> fre. 26. apr. 2019 kl. 19:58 skrev Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org>: > One thing that I think is missing from the article in the discussion of > pros and cons is that in many cases a large or even voluminous request can > be sent via auto submitting form post (like > https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but > the other way around from client to AS with the auth request), which > doesn't then run into the same URI size problem. > > From a prospective standardization standpoint, there are really two > distinct concepts in the article. One is the "Pushed Request Object" and > the other the "Structured Scope". They are certainly complementary things > but each could also be useful and used independently of one another. So I'd > argue that they should be developed independently too. > > > > On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi all, >> >> I just published an article about the subject at: >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948 >> <https://medium..com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948> >> >> >> I look forward to getting your feedback. >> >> kind regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
