Re: [OAUTH-WG] An access token claim to identify data processing purposes
Hi N, Il giorno lun 4 apr 2022 alle ore 18:08 Steinar Noem ha scritto: > Ah, for machine-to-machine the eKYC/IA spec is not relevant - as it requires > an interactive session (an authenticated user). Ok. Could that information be vouched by a third party though? > But the Rich Authorization Spec (authorization_details) describes how to > express more information related to a grant, so that would be fitting I would > think. > We use the structure for accountability purposes, legal basis and legitimate > interest - and reflect certain claims in the access token (JWT). If this is related to public sector API, it would be really interesting to discuss that topic and see some examples! Have a nice day, R. > > man. 4. apr. 2022 kl. 18:02 skrev Roberto Polli : >> >> Thanks Noem, >> >> Il giorno lun 4 apr 2022 alle ore 16:32 Steinar Noem ha >> scritto: >> >> I'm looking for a standard way to express data processing purposes in >> >> access token/requests. >> >>E.g an access token request/response should provide an identifier linked >> >>to the reason that motivates >> > Maybe you’ll find the work on RAR and identity assurance in OIDF >> > interesting? >> > RAR could be used for indicating a “legitimate interest”, and IA could >> > cater for accountability. >> >> You mean the authorization_details and verified_claims ? >> Interesting! Is was wondering whether there was something more concise, >> but I will investigate if that's viable for a machine-to-machine interaction >> like the one >> I'm working on. >> >> Thanks again, >> R: >> > > > -- > 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
Re: [OAUTH-WG] An access token claim to identify data processing purposes
Thanks Noem, Il giorno lun 4 apr 2022 alle ore 16:32 Steinar Noem ha scritto: >> I'm looking for a standard way to express data processing purposes in access token/requests. >>E.g an access token request/response should provide an identifier linked to the reason that motivates > Maybe you’ll find the work on RAR and identity assurance in OIDF interesting? > RAR could be used for indicating a “legitimate interest”, and IA could cater for accountability. You mean the authorization_details and verified_claims ? Interesting! Is was wondering whether there was something more concise, but I will investigate if that's viable for a machine-to-machine interaction like the one I'm working on. Thanks again, R: ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] An access token claim to identify data processing purposes
Hi folks, I'm finding a standard way to express data processing purposes in access token/requests. E.g an access token request/response should provide an identifier linked to the reason that motivates a specific data processing. The first idea is that this identifier is conveyed in a custom claim, but maybe there's an existing claim/access token request parameter already. If such a parameter does not exist, which is the procedure for registering it? Kind regards, R: ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for DPoP Document
Dear all, thanks for this interesting work! I think that there's some editorial work that should be done on terminology (e.g. a consistent use of JOSE header parameter, HTTP header field, ...) and some simplification will really make the spec more easy to read. For example, once defined that the syntax of DPOP is a JWS, it is redundant to further state that DPOP value MUST be a JWS. Moreover there are security considerations all throughout the document, that should probably be moved to the #Security section. I will provide further feedback in the next few days. I'm providing some PRs on the repo: feel free to comment there. - https://github.com/danielfett/draft-dpop/pulls/ioggstream Kind regards, R. Il giorno lun 28 mar 2022 alle ore 14:01 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > All, > > As discussed during the IETF meeting in *Vienna* last week, this is a *WG > Last Call *for the *DPoP* document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > > Please, provide your feedback on the mailing list by April 11th. > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] oauth-access-token-jwt: comments and clarifications
Hi Vittorio et al,
some considerations on oauth access token jwt follows.
You can see them here too
https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit
An example with client_credential grant type would be nice too.
My 2¢,
R.
§ 1.2 Terminology
+ The terms "Collision-Resistant", is used according to Section 2 of
{{JWT}}.
§2.1 Header
- mentioning "none" alg can be redundant. I'd reference all the JWT BCP
instead.
- I'd add an example header, eg
~~~ example
{
"typ": "at+jwt",
"alg": "PS256"
}
~~~
§ 2.2.1 Authentication Information Claims
Is it worth mentioning the "implicit flow"?
§2.2.2 Identity Claims
- use the "Collision-Resistant" definition in {{JWT}}
§2.2.3 Authorization Claims
- " ... scope parameter..." should `scope` be quoted?
- "All the individual scope strings in the "scope" claim MUST have meaning
for the resources indicated in the "aud" claim."
^ otherwise the error returned is ...? Should we reference §4 here?
§2.2.3.1 Claims for Authorization Outside of Delegation Scenarios
- which are the delegated scenarios described in RFC7519? Do you refer to
"When using an administratively delegated
namespace" ? It is not clear to a first-reader.
§3 Requesting a JWT Access Token
- an example with `client_credential` grant type would be great.
- iiuc `jti` is required, the example does not report it.
§4 Validating JWT Access Tokens
- the step about forbidding "none" is limitative WRT JWT BCP 8725
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Digest for DPoP
Hi @all, I'm planning to read those I-D as they might be useful in a project, and I'm happy to provide feedback on digest usage. In general, when building protocols over HTTP it is necessary to take into account the semantics (eg. range requests, caching, ...) because reverse proxies, WAF and api gateways implement them: this is true whether you use digest or other fields. Is there a git repo to provide feedback? I hope to do it in the next few weeks.. Have a nice day, R: Il giorno ven 19 feb 2021 alle ore 22:51 Brian Campbell ha scritto: > > My inclination is to keep digest[1] out of the base DPoP document. I do > believe that including it would add unneeded complexity to regular old DPoP > (there are some subtleties around digest that make it more complicated than > one might expect) and, from a design philosophy perspective, DPoP has always > aspired to be only a proof-of-possession mechanism in and of itself and not > venture into the realm of HTTP message integrity or general signatures. > > > [1] Note that the digest header is defined in RFC3230 but there's work > underway to obsolete that RFC with draft-ietf-httpbis-digest-headers-04 > > > On Wed, Feb 17, 2021 at 2:54 PM Justin Richer wrote: >> >> Two different specifications (GNAP and FAPI signatures) have recently >> profiled DPoP to use its signature method to protect a different kind of >> protocol entirely. One thing these methods have in common is that they both >> define an additional field for holding a digest of the HTTP Message Body: >> >> https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body >> >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p >> >> Both of these have the same semantics, and we’re changing the name in GNAP >> to align with the FAPI one. This begs the question: do we want to just >> define this field as an optional component in DPoP instead of having these >> profiles do it separately? It would save them from needing to align with >> each other, and anyone else from inventing it again. >> >> Is it worth defining this in DPoP directly, or does that complicate the spec >> too much? I’ve previously raised a similar question on including a hash of >> the access token in the DPoP request to the RS. >> >> — Justin >> ___ >> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.1 and TLS
Hi everybody, I provided some feedback on TLS usage on OAuth 2.1. You can find it in this commentable PR: - https://github.com/aaronpk/oauth-v2-1/pull/30/files As a first-time reader of this I-D I found that the various references to TLS were a bit confusing because: - sometimes it was explicitly stated as MUST - sometimes it was not mentioned - in other parts it's MAY not use TLS (eg. `loopback`). Moreover various information on how to process TLS were given: I am not sure whether this makes the spec more secure or less secure, as there are spec related to TLS security including RFC8740 which does not seem to be included (it's not in BCP195, which applies to TLS<=1.2). Probably we need a way to delegate elsewhere all the quirks of TLS/whatever channel security mechanism is used. The general idea of the above PR is to: - move everything about TLS to a specific section; - state that MUST TLS unless `loopback`; - further quotes of TLS are expected to be non-normative. Feedback welcome, R ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.1: improving terminology and relationship with other specs
Hi @all, I have recently started looking at OAuth2.1 spec and I proposed to align the terminology with the HTTP spec: - https://github.com/aaronpk/oauth-v2-1/pull/22 I suspect that more work on this field would improve the spec, eg: - https://github.com/aaronpk/oauth-v2-1/issues/created_by/ioggstream but I'd like to hear from you. Have a nice day, R. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Providing feedback to OAuth2.1
Hi everybody, I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo (eg. like https://github.com/httpwg/http-core) where I can see the open issues, catch up with the discussion and discuss PRs? Thanks for your hard work and have a nice day, R: ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
