OIDF-automation

### Imported from AB/Connect bitbucket - Original Commenter: danielfett Following offline conversations, I’d like to re-open this issue. Besides the points raised above - one endpoint less to protect and...

### Imported from AB/Connect bitbucket - Original Commenter: danielfett See comment.

### Imported from AB/Connect bitbucket - Original Commenter: danielfett In the SIOP call, a case was discussed where the Wallet might not know how many credentials are to be issued....

### Imported from AB/Connect bitbucket - Original Commenter: sloops77 yes - if i understand this correctly it also means that result can be cached by the wallet

### Imported from AB/Connect bitbucket - Original Commenter: pedro-felix * Would this mechanism also be applied when retrieving the issuer metadata \(and not an offer\)? * Are you considering something...

### Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda yes, Accept-Language HTTP request header would work!

### Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt The parameters you listed don’t make sense as they are typically used by the AS to check whether the actual request...

### Imported from AB/Connect bitbucket - Original Commenter: dwc8 I think if we specify the trust model that we are using for both issuing and presenting VCs then it will...

### Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda I made the first pass to what I think should be allowed/prohibited/conditional: **For both OID4VP and SIOPv2** * Prohibited * redirect\_uris...

### Imported from AB/Connect bitbucket - Original Commenter: peppelinux **default\_acr\_values** this may depends by each presented VC. Let’s suppose that we may have different credentials of the same type but...