sharing grant_id among different clients
Issue #378
resolved
The draft dare state that grant_id may be shared among different clients, but I'm concerned about the idea. If it is allowed, an entity can collect a big set of permissions by releasing many client applications even if the number of permissions requested by each of the client applications may be small.
Comments (18)
-
-
Thanks @Takahiko Kawasaki . The intent was to allow to “bind” a grant to an organisation that owns the client, not just to the client_id itself. The organisation might have different applications / clients that might share the grants.
The specification doesn’t prescribe this behaviour, it just makes sure it’s possible if a specific ecosystem needs it.
May be we could add some privacy considerations to avoid accumulating permissions scenario?
@Ralph Bragg May be we should be more specific, I just don’t know how. May be something along the lines “controlled by the same entity as long as a user has provided authorisation to this entity”.
Alternative is to remove this completely (bind to client_id) until we can define “Client“ in a more precise way.
-
Note that In addition to “
grant_idpotentially could be shared by different client_id belonging to the same entity.” the current document also has this:Note: a client (as logical entity) MAY use multiple client ids to deliver its service across different platforms, e.g. apps for iOS and Android and a Web App. It is RECOMMENDED that the AS supports sharing of grants among client ids belonging to the same client. Sector identifier URIs as defined in [@OpenID.Registration] is one option to group client ids under single administrative control.
-
It seems like without binding to the client, there’s an opportunity for something like a grant id fixation attack with update. I’d have to think thought it a little more but it seems dangerous.
I’d also suggest that rather than “mak[ing] sure it’s possible if a specific ecosystem needs it” what’s in the document currently is a recipe for implementation difficulties and interoperability problems. And maybe security issues too.
The sharing behavior should probably be well defined. Or failing that, omitted.
-
There’s some reasonably decent use cases for sharing of grant information between clients including a really common one we’ve been seeing which offers consent management across many different clients grants in a unified way. Unfortunately, as nice as this use case is it is exposed to potential vulnerabilities.
As much as I would like to omit it as per Brian’s suggestion I think that’d leave a pretty big hole in the spec. Consequently, @Takahiko Kawasaki @Brian Campbell do you have any suggestions how we could make sharing of grant id’s among clients possible/safer? Additional scope? Some form of opt-in during establishment?
-
Stuart, the use case here is the same organisation having different clients that can potentially share grants (assuming trust and legal ecosystem allows it).
This is not the use case where grants become the resource in their own right to be shared with completely unrelated parties (centralised / unified consent management). My view is that there needs to be a separate authorisation for this use cases and the RS will server this data via separate API.
-
-
assigned issue to
Stuart Low
-
assigned issue to
-
Attempting to clarify this: https://bitbucket.org/openid/fapi/pull-requests/261
-
@Brian Campbell @Takahiko Kawasaki @Ralph Bragg Have attempted to clarify this within the above PR such that “sharing” is limited to a single administrative entity.
-
New term! Administrative Entity.
It’s been a while since we introduced a new term, the previous lot were beginning to become too widely understood.
-
Initial version of this spec could limit visibility of the grant to the creating client.
This does not prevent the an AS to change the binding and allow for sharing of grant among clients. This behavior nevertheless does not need to be included into the current spec as we haven’t detailed all security implications for now.
-
With evolving market experience we can keep collecting and detailing use cases (with respect to their security implication and consequence on the grant life cycle). Mature uses cases can then lead to the extension of the spec in future versions.
-
Reiterating (by request) comments from the call this morning: if the document wants to support sharing grant_ids, it needs to define it sufficiently for interoperability to be achieved and security ensured. PR #261 doesn’t achieve that.
-
After discussion with Torsten we decided to keep this out of scope for the first implementers draft.
We still believe there is a use case for sharing client ids limited to a single administrative entity but acknowledge this needs additional work before including it into the specification.
-
-
-
- changed status to resolved
PR prepared and being merged
-
Similar issue discussed in : https://bitbucket.org/openid/fapi/issues/326/grant-anchor
- Log in to comment
The spec does need to make clear if it is binding to client_id or client. I don’t see a problem if technically the binding and grouping is left up to ecosystem specific requirements like a ‘client’ or ‘organisation’ or ‘owner of an SSA’ or ‘federation identity’ instead of something technically specific like client_id. However the intention needs to be made clear one way or another so the bug perhaps should be to request a action to , ‘Define Client’.