4 ms·

Public keys solve the key management problem. If you have just one or two tiers it's not a problem. If you have thousands, you end up spending a lot of time on

by kpil 9y ago

Public keys solve the key management problem. If you have just one or two tiers it's not a problem. If you have thousands, you end up spending a lot of time on key distribution if you need individually distributed secret keys.

lvh 9y ago
You say that, but best practice for systems that have that option (say, internal SAML IdPs) still means you do per-peer keys with the annoying key management problem so that you get cryptographic binding instead of relying on a bunch of broken RPs to validate audience restrictions (spoiler: they don't) and in some cases IdPs or middleboxes that need to add audience restrictions (spoiler: they don't either). What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.) What do you mean by "tiers" here? The specificity of that word suggest you don't just mean "peers", but at the same time clearly symmetric systems win at nested delegation. (krb5, macaroons come to mind)
- zeveb 9y ago
  > What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.) You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be useful.
  - tptacek 9y ago
    This feels like grasping at straws.
  - lvh 9y ago
    I don't think I could've made my own point this elegantly. Eventually trying to disprove what the other party is saying is literally the opposite of what normal token schemes (say, SAML or OIDC JWT) is trying to accomplish: trying to establish what the other party is claiming.

by kpil 9y ago

lvh 9y ago

You say that, but best practice for systems that have that option (say, internal SAML IdPs) still means you do per-peer keys with the annoying key management problem so that you get cryptographic binding instead of relying on a bunch of broken RPs to validate audience restrictions (spoiler: they don't) and in some cases IdPs or middleboxes that need to add audience restrictions (spoiler: they don't either). What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.) What do you mean by "tiers" here? The specificity of that word suggest you don't just mean "peers", but at the same time clearly symmetric systems win at nested delegation. (krb5, macaroons come to mind)

zeveb 9y ago
> What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.) You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be useful.
- tptacek 9y ago
  This feels like grasping at straws.
- lvh 9y ago
  I don't think I could've made my own point this elegantly. Eventually trying to disprove what the other party is saying is literally the opposite of what normal token schemes (say, SAML or OIDC JWT) is trying to accomplish: trying to establish what the other party is claiming.