You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have the concept of a control_requirement that consists of control-id, name and description.
When we think of controls these are usually backed by a control statement, a control statement being the reason for a control in the first place.
Lets take the OAuth2 spec there are various control statements in the RFC e.g.
the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication
The name of these are the description are different.
e.g.
{
"control-id": "TLS-001",
"name": "Mandatory TLS Support",
"description": "The Authorization server must support TLS version 1.2 or newer",
"statement": "The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication"
}
Potential Solutions:
The first solution I'd like to propose is to add the statement as a mandatory field in control_requirement, if we believe that all control requirements have a control statement then it should be placed here
The second solutions I believe is to extend control_requirement within the security domain to add a new policy type that includes all of the control_requirement as well as adding in the statement field. I have created a draft PR of what I think it would like to help with the discussion: #687 WIP to help with the Issue discussion #688
It would be great to hear what others think on this subject
I'm personally of the view that yourself and @aldwin-ms are our security experts. We can discuss on office hours, but I think if this is your proposal we should adopt it, certainly this is not yet in active use so we're not going to break anyone.
A couple of questions I would have though are:
Should it be control-statement to be explicit? I know it is in a control so is implicit but in the same way we use control-id rather than unique-id may be stronger?
If we add this, does is sufficiently replace description that it's just duplicative?
Feature Request
Currently we have the concept of a control_requirement that consists of
control-id
,name
anddescription
.When we think of controls these are usually backed by a control statement, a control statement being the reason for a control in the first place.
Lets take the OAuth2 spec there are various control statements in the RFC e.g.
the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication
The name of these are the description are different.
e.g.
Potential Solutions:
statement
as a mandatory field in control_requirement, if we believe that all control requirements have a control statement then it should be placed hereIt would be great to hear what others think on this subject
TAG: @aldwins-ms @jpgough-ms @yt-ms @rocketstack-matt
The text was updated successfully, but these errors were encountered: