Simplify security?

[jonathanrobie]

Can we simplify security in RADL?

What a client needs to know is:

• Which resources require authentication
• Which authentication scheme(s) are used for each resource
• How to respond to a challenge - documentation for each scheme used

Does the client need to care about identity providers? Aren't these chosen by the server? Obviously, the client does need to know the authentication scheme.

We have a separate section for headers and status codes needed for authentication. Why don't we just use the common conventions for this? They are straight HTTP.

RAML models schemes, but not mechanisms or identity providers. Can we do the same?

[RaySinnema]

The client doesn't need to care about identity providers. Neither does it need to care about resources. We put those in for the server team, and the same is true for identity providers.

[RaySinnema]

The headers and status codes are references to those in the conventions. I don't remember why we did that. I see no problem in removing them.

[RaySinnema]

We have the mechanism element to declare supported authentication mechanisms. A given mechanism could support multiple schemes. That's the case for HTTP Authentication, for instance.

If we merge mechanism and scheme into one, we are basically mandating HTTP Authentication. That works for my projects and probably for most, but not for all. For instance, AWS has two methods of authentication, one of which uses query string parameters. I'm not sure that RADL would be able to describe that if we merged mechanism and scheme.

The question is whether we care enough about such edge cases to take the complexity hit?

[jatoko]

So how do you signal a client when and what authentication method to use?