I am developing an ocap 'permission request file' to grant/fetch permissions for my application.
I am referring MHP1.2, particularly chapter 12 - Security in the spec.
Is <file> permission request is for requesting access to persistent files? I do not understand the necessity of this when <persistentfilecredential> is available. Can someone explain?
What does it mean if I specify <file value'"false"></file> in my permission request file?
The spec says Conditional Access Permission is optional. But if present, the DTD definition for CA Permission is <!ELEMENT capermission (casystemid)+> and casystemid has a files "id" which is REQUIRED.
Who defines "casystemids"? Or simply what value should I use for a casystemid?
I would really appreciate your help.
Another question added:
There is a reference to "CA System ID" in the DCD (Downstream Channel Descriptor) and I am wondering if this is the one we are referring in the PRF (Permission Request File)?
Just curious, would appreciate any help or information.
Let me explain as far as I know.
Answer to your First question :
<flie> is not a element of PFR but of application description file. So <file> is not about any permission.
So <persistentfilecredential> is necessary for the request of permission for access to file credential.
If you are seeing MHP 1.2, you can check section '18.104.22.168 Credentials' for details of the usage and purpose.
the only resource that can be
contained in a credential is a file (or a set of files of a directory). Credentials shall not grant access to directories, only
files within them.
Second question :
I guess DVB or CableLabs who make specifications of this interactive TV industry,
they define and publish the values.
I guess those should be same value as assinged and it is from CA Id descriptor.
You can refer to section 'O.2.9.1' of MHP 1.2
Returns the array of integer values containing the CA_system_ids from the CA identifier descriptor. If the CA identifier
descriptor is not present, returns an empty array.
First, thank you for your response and for the information. I appreciate it.
I humbly disagree on your first response that <file> is not an element of PRF (Permissions Request File).
Well in Application Description File, there is an element - <file> and also in Permission Request File.
In section 22.214.171.124.4 of MHP1.2, the DTD for the Permission Request File has the following definition:
<!ELEMENT permissionrequestfile (file?,capermission?,,......etc.,)
<!ELEMENT file EMPTY>
value (true|false) "true">
I was referring to this element <file> in my question.
Thanks for the explanation about Persist File Credential. Now, why element <file> when there is an
element <persistfilecredential> in Permission Request File? Please clarify?
Regarding, getCASystemIds(), thanks for pointing this out but someone (like me) who is defining a
Permission Request File for my application do not have the access to call this API, I mean I am
defining PRF to sign my application and so I am not touching my source and no compilation involved
at this point of time. Do you see my point? If not let me know, I will try in another way.
Thanks again for your time and information.
Thank you. I just wanted to share what I have learned from field experiences.
There might be some misunderstanding from my side. But I am glad to having this discussion with you.
Let's find the truth :-)
- I didn't know there are <file> element in PRF DTD as you refered 126.96.36.199.4
and don't feel any necessity of <file> element while there is already <persistentfilecredential> which is used for same intended purpose.
I think there might be possibility of typo in the spec document also. Do you want me to figure out more closely?
I can contact DVB TAM and MUG chairs for this questions.
- Sorry, I can't fully understand what you are trying with getCASystemIds() API.
What I mentioned was just a general understanding of my own because I haven't have any experience with this APIs usage.
If you can contact DVB TAM and MUG chairs I would be very glad and I would be more glad if you would include "me" in the conversations with them :-)
Coming to CA System Id's, lets ignore it as it is not that important.