Hm, interesting Warren. AWS feels like both the AS and RS in this scenario; I don’t see any reason why these have to be separate entities.
> > On 20 Oct 2021, at 7:48 pm, Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > wrote: > > > There is a pattern, where a user configures one credentialed entity for > access to a RS, but controls neither the credentialed entity nor the RS. I > might say technically the user is acting as the AS, but it isn't clear to me. > > Concretely, CI/CD services such as GitHub and GitLab support runners that > come with a JWT, whom this JWT should be issued to is not exactly clear. > These tokens are intended to be used with third party RS such as AWS IAM to > authenticate and access resources in AWS. (AWS reference) > > Currently, GitLab is prototyping support for this access and wants to know > what's a good meaningful value for the AUD to be. (GitLab context) > > Personally, while I'm able to specify who is the client, RS, and AS, it > doesn't feel exactly like it's something directly supported by any RFC, but > it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server = > AS) > > Due to the nature of what's available for configuration on both sides, it's > likely they want to go with altering the AUD to point itself at the git > repository url where the token comes from rather than the RS which would like > be the AWS account. The closing thought I have is if we suspend for one > moment expectations about who is authorization by whom, it's possible to also > see that AWS is the AS, and the gitlab runner is a client using the > jwt-bearer credentials grant. > > Is there anyone that wants to weigh in on this, it's a potentially great > opportunity to drive the right practice at the right time. > > (I'm happy to relay any outcome back to the thread or feel free to post > directly on the Gitlab issue. > > - Warren > > > Warren Parad > Founder, CTO > Secure your user data with IAM authorization as a service. Implement Authress. > _______________________________________________ > 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
