Hi all, John,
So I reviewed the oauth-dyn-reg-17 with the goal of finding more info on the
following statement in your previous email
"Since the publishing of this RFC we have also developed a spec for dynamic
client registration so it is possible to give every native client it's own
client_id and secret making them confidential clients."
If I understand the draft correctly, you can turn a native client from
public to confidential only if the following is true:
1) The client must be able to dynamically register with the
registration endpoint and download an instance-specific client ID and a
temporary ("expirable") client secret on the fly.
2) Although the client cannot maintain the secrecy of any secrets
packaged within client software, it needs to be able to maintain the secrecy
of a per-instance client secret.
So here are my questions: I am not quite sure what provides the trust in
this scenario. The client is using a secret that it was just given by the
registration end point (essentially hosted by authorization server?) to
authenticate to the same authorization server? Unless an out of band trust
relationship was used (initial access token??), we don't have any additional
trust in client or its ability to hold secrets. The only added benefit by
dynamic registration in the way of above is that (as I see it), because the
ID and secret are instance specific, their compromise only leads to the
compromise of just that client and just that user's data, rather than the
entire populations. Or the point is that we are saying there are
clients/scenarios that can be trusted with short term secrets but not long
term secrets?
Am I missing something?
I could see that if we had required an out of band trust relationship, for
instance requirement of a protected dynamic registration (use of initial
access token that is client instance specific), not sure how the two above
helps an individual user?
My other comment regarding the drafts are as follows:
1) The draft is somewhat asymmetric with respect to the use of software
statement versus initial access token. Although, the specs says that they
are both choices of methods of attestations, only Initial access token is
required for protected registration, while software statement is declared
orthogonal to open versus protected registration. Since spec is silent on
creation of initial access token generation, it is hard to see what
qualifies the initial access token but not software statement.
2) Software statement is a signed/ MACed statement of a subset (or
none, since they are all optional) of client meta data but not the client
software itself. So question is do I have any protection if the client
software itself is modified maliciously (even though the metadata is still
the same)?
Thanks in advance,
Madjid
_________________________________________________
Madjid Nakhjiri | Technical Director, Security Architect
Samsung SDS Research America
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
