(Atul) Does the interop spec talk about the code flow outside of the FAPI example?
(Thomas) It says that it must "support client or code flow"
(Atul) - I think that Apple is using the authZ code flow as part of their enrollment process
(atul) - in the first launch of the certification, we can just not suppport the code flow, and then update it to support code flow later on?
(approva) - we can just leave the code flow in the spec, becuase there are other vendors that may be using it
(Atul) - agreed. Not intending to change the spec, just to phase in the support for certification
(Apporva) - What if we just remove the grant flows constraints all together, and just imply that you should use some kind of access token and honor scopes, without specifying oauth flows...
(Atul) - Both are allowed for the interop spec, but the certification will only be for client cred flow. Apple is currently not on the latest spec, and so they wouldn't be able to qualify anwyway
(Thomas) - How would interop work anyway, if Apple requires auth code flow, and no one else supports it? Maybe we drop it temporarily and then add it back in later on? Because then we would be blocked on providing a certification if we can't do the whole interop spec
(atul) - I think that's ok if we have an agreement to support it later on. Apple does work with many IDPs and they support the client flow instead
(Approva) - I don't support dropping the auth code flow becuase there may be implementations already using it
(Thomas) - does this token from Auth code last for the lifetime?
(Atul) - not sure of the lifetime, it may be just for stream creation, not sure
(Apporva) - Apple is on the older implementation - setting up and then maybe updating it later on (not sure, to be honest what their process is). They don't support verification later on, they accept verification events, but they dont' request one
(Atul)_ - that's how they know the stream is working though, I think
(Thomas) - are their any other known implementations that are using it?
(Apporva) - There are some partners that are using it, but I dont' have the details at the moment
(John) - Same here for JAMF partners
(Yair) - this is more of a server to server setup ; apple is doing that as part of a larger flow. This is all part of the configuration of the IDP - from their perspective it's ok, because it's a one time config of an IDP (rather than repeated verification)
(Atul) - I know that Apple is working on updateing their implementation, so that might be another path forward. I don't think that the way that Apple is doing OAuth is non-standard. The time pressure / architecture issues are real , so I think we should launch the conformance tests without Auth Code being supported for now
(Thomas) - So since I am preparing the release of the conformance tests at the moment, then if the WG agrees to this, then we'll document that as we release it (that it only works with client crednetials) - and that before someone purchases certification, they should be aware of that issue
(Thomas) - next issue: what is the granularity of the transmitter tests? Is any client authentication allowed, or do they have to pass tests with all/every form of client authentication?
(Atul) what did we use in the past?
(Thomas ) - it varied - some are static access tokens, or you could configure client id/ secret, etc ... Most used client flow...
(Atul) - should we support both?
(Yair) - The other option ... not every transmitter / receiver will support all of them... What are we certifying for? ie - push vs poll ... Shouldn't need to support ALL authenticaiton methods ....
(Atul) a goal (for me) is that once you pass the certified test, then you should expect that it works with other certified implementations. A minimum baseline is a good idea
(Apporva) - we have push / poll and we'll diverge on that ...
(Thomas) - that's the next set of tests - what is supported (ie push / poll). Adding too many combinations leads to complexity
(Apporva) - Initially, we just wanted to make sure that OAuth became the standard for authZ. As long as we can prove that the tokens and scopes are supported.... Does flow hamper interoperability?
(atul) - We're saying that you use OAuth - how you get the token is out of band (we shouldn't care how you get it). One of the reasons that we put into the spec that one side (trans?) has to support push / poll was to increase interoperability. Kind of resigned to the fact that push/ poll may separate conformance tests.
(Thomas) - we were going to publish vendor xxx or yyyy will support push / poll and these kinds of events....
(Apporva) - if we add another channel of communication, then the stringent demand that all is supported would become a blocker...
(Mike) Publishing a certification test with parameterization for push / poll is OK. To accelerate adoption, I would like to also make sure that a Transmitter supports specific CAEP events.
(Thomas) The CAEP interop spec specifies 2 events that are required to be implemented. But right now, there's no way to prompt the transmitter to send a specific event, so there's no way to test it.
(Mike) - having a way to force a transmitter to create the required events helped interop greatly...
(Atul) - the spec states that we require the two CAEP events. Can we have the transmitter just sent the events on its own without being prompted to do so (for the purpose of the conformance test)...
(Thomas) - that's how it works at the moment...
(Apporva) - Clarifying - the spec says "one of the events" not all the events
(Yair) - not all, any, correct?
(Apporva) - yes...
( Atul) - maybe we just add the device change event?
(Yair) - what about the risk level change event? I think that will be popular...
(Atul) - Conformance tests could reveal which events, but only support a few events for now (to get started). And we can make the spec change as well...
(Thomas) - can add device compliance change - is one event enough? The reciever would just listen for an event and then check to see if matches what was requested...
(Atul) - request all 3, and then see what the transmitter supports, and then just expect those events
(Ashish) - a common open-source protocol issue is paramerization - making sure that they support a simple certification is important for adoption purposes.
(Atul) - what we're trying to do is make the bar to passing a certification as low (easy) as possible.
(Ashish) - the docs can clarify that without it having to be within the conformance test.
(Thomas) - Want to make sure that I have this correct:
Atul asked to add device compliance events
The test will request all events, and then look at what events are supported, and that's what the test will look for. (if it's empty, then it's an immediate fail)
The statements about granularity of conformanc:
Suggested Certification Statement Variants (Oauth2 based Auth implied)