OIDF-automation

### Imported from AB/Connect bitbucket - Original Commenter: bellebaum @{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} Currently, devices are authenticating themselves in a `client_credentials` flow with [signed JWT Bearers](https://datatracker.ietf.org/doc/html/rfc7523#section-2.2) as Client Assertions using pre-registered keys. To...

### Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt You basically use pre-registered keys to directly authenticate the subject of the credential to be issued, correct? Do you use the...

### Imported from AB/Connect bitbucket - Original Commenter: bellebaum Essentially yes, the subject identifiers will either be the the client IDs directly or derivations thereof, to fit the format \(e.g....

### Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt Thanks for the explanation. I just wanted to find out what is the client and what is the subject of the...

### Imported from AB/Connect bitbucket - Original Commenter: bellebaum Yes, if I have not overlooked anything, that would pretty much cover the use case. Questions we would then have to...

### Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt On dynamic credential input: wouldn’t `vp_token` support in the token request solve that problem?

### Imported from AB/Connect bitbucket - Original Commenter: bellebaum I think we might read “dynamic credential input” differently there. My understanding was that when using dynamic input, the Issuer is...

### Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt You are right :wink: `vp_token` is part of the "static" approach.

### Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda I would assume basing credential issuance flow on OAuth as opposed to OIDC does not solve this issue?

### Imported from AB/Connect bitbucket - Original Commenter: mbj Kristina, I believe you’re right that the switch to OAuth doesn’t change things with respect to this issue. I believe that...