> I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
BankID could have designed their API such that "person performing the action" and "subject the action applies to" are different fields.
But even that is unnecesary. Who actually requested the action only concerns the subject, not the third party carrying it out. BankID could simply log "Delegate A requested entity B to perform action C on behalf of subject D" and show it to D, while keeping B completely in the dark.
It would likely be very problematic for the security model as it is crucial that you only sign your own requests that you understand what they do. I guess you can technically sign someone else's request made with your identification number today as most service don't use QR codes for presence verification. In general I am also not sure that further expanding, and blurring the line, of what you can do with BankID is a good idea. If anything I would like more limits.
And therein lies the problem.
> Re: most, really? There are some that don't accept non-mobile BankID, but it is uncommon in my experience.
You already refuted this yourself in https://news.ycombinator.com/item?id=20656033.
> I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
BankID could have designed their API such that "person performing the action" and "subject the action applies to" are different fields.
But even that is unnecesary. Who actually requested the action only concerns the subject, not the third party carrying it out. BankID could simply log "Delegate A requested entity B to perform action C on behalf of subject D" and show it to D, while keeping B completely in the dark.